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The  NATO  Science  and  Technology  Organization 


Science  &  Technology  (S&T)  in  the  NATO  context  is  defined  as  the  selective  and  rigorous  generation  and  application  of 
state-of-the-art,  validated  knowledge  for  defence  and  security  purposes.  S&T  activities  embrace  scientific  research, 
technology  development,  transition,  application  and  field-testing,  experimentation  and  a  range  of  related  scientific 
activities  that  include  systems  engineering,  operational  research  and  analysis,  synthesis,  integration  and  validation  of 
knowledge  derived  through  the  scientific  method. 

In  NATO,  S&T  is  addressed  using  different  business  models,  namely  a  collaborative  business  model  where  NATO 
provides  a  forum  where  NATO  Nations  and  partner  Nations  elect  to  use  their  national  resources  to  define,  conduct  and 
promote  cooperative  research  and  information  exchange,  and  secondly  an  in-house  delivery  business  model  where  S&T 
activities  are  conducted  in  a  NATO  dedicated  executive  body,  having  its  own  personnel,  capabilities  and  infrastructure. 

The  mission  of  the  NATO  Science  &  Technology  Organization  (STO)  is  to  help  position  the  Nations’  and  NATO’s  S&T 
investments  as  a  strategic  enabler  of  the  knowledge  and  technology  advantage  for  the  defence  and  security  posture  of 
NATO  Nations  and  partner  Nations,  by  conducting  and  promoting  S&T  activities  that  augment  and  leverage  the 
capabilities  and  programmes  of  the  Alliance,  of  the  NATO  Nations  and  the  partner  Nations,  in  support  of  NATO’s 
objectives,  and  contributing  to  NATO’s  ability  to  enable  and  influence  security  and  defence  related  capability 
development  and  threat  mitigation  in  NATO  Nations  and  partner  Nations,  in  accordance  with  NATO  policies. 


The  total  spectrum  of  this  collaborative  effort  is  addressed  by  six  Technical  Panels  who  manage  a  wide  range  of 
scientific  research  activities,  a  Group  specialising  in  modelling  and  simulation,  plus  a  Committee  dedicated  to 
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well  as  recognised  world-class  scientists,  engineers  and  information  specialists.  In  addition  to  providing  critical 
technical  oversight,  they  also  provide  a  communication  link  to  military  users  and  other  NATO  bodies. 


The  scientific  and  technological  work  is  carried  out  by  Technical  Teams,  created  under  one  or  more  of  these  eight 
bodies,  for  specific  research  activities  which  have  a  defined  duration.  These  research  activities  can  take  a  variety  of 
forms,  including  Task  Groups,  Workshops,  Symposia,  Specialists’  Meetings,  Lecture  Series  and  Technical  Courses. 
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Executive  Summary 

As  simulation  interoperability  was  the  highest  priority  capability  gap  of  the  NMSG  MORS  M&S  Gap 
Analysis  Questionnaire  an  Exploratory  Team  (ET-027)  of  the  NMSG  was  formed  in  2009  to  investigate 
simulation  interoperability.  ET-027  identified  63  issues  which  severely  limit  simulation  interoperability. 
Based  on  the  findings  of  ET-027,  MSG-086  “Simulation  Interoperability”  was  initiated  in  2010  and  tasked  to 
analyse  the  ET-027  interoperability  issues.  This  analysis  should  be  used  to  recommend  and  prototype 
information  products  augmenting  the  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP) 
[DSEEP]  to  mitigate  or  obviate  identified  interoperability  issues.  In  total,  46  interoperability  issues  are 
identified  and  described  by  MSG-086  and  categorized  into  9  interoperability  issue  groups.  All  issues  are 
documented  according  to  the  same  schema  and  relations  to  relevant  M&S  standards  are  identified. 

Present  standards  for  distributed  simulation  environments  mostly  focus  on  the  technical,  the  syntactic  and 
(to  a  limited  extent)  on  the  semantic  interoperability  level.  To  meet  future  demands  -  especially  in  terms  of 
quality  and  reduced  time  and  costs  -  simulation  interoperability  at  higher  levels  (i.e.,  on  the  pragmatic, 
dynamic,  and  conceptual  interoperability  level)  is  required  as  well  as  substantial  automation  of  development, 
integration,  and  execution  of  distributed  simulation  environments. 

This  requires  standardization  of  information  products  created  in  the  process  of  developing  a  simulation 
environment,  following  e.g.,  the  DSEEP.  Such  standardized  information  products  must  address  higher  levels 
of  interoperability  than  present  simulation  interoperability  standards  which  focus  on  lower  interoperability 
levels  (i.e.,  on  technical,  syntactic,  and  semantic  issues). 

Based  on  the  identified  interoperability  issues  and  their  impact  on  the  simulation  environment  engineering 
process,  MSG-086  focused  its  further  efforts  on  the  issue  group  “Scenario”.  To  improve  simulation 
interoperability  in  context  of  the  DSEEP,  MSG-086  developed  a  “Guideline  on  Scenario  Development  for 
(Distributed)  Simulation  Environments”.  This  guideline  augments  the  DSEEP  with  regards  to  scenario 
development  and  proposes  content  and  structure  of  an  information  product  for  scenario  specification. 

Additionally,  MSG-086  delivers  the  following  secondary  outcomes  and  deliverables: 

•  Recommendations  for  updating  AMSP-0 1  [AMSP-0 1  ]  with  respect  to  simulation  interoperability 
and  scenario  development. 

•  A  proposal  for  updating  the  NMSG  Military  Operational  Requirements  Sub-group  (MORS)  M&S 
Gap  Analysis  Questionnaire. 

•  Recommendations  for  SISO  working  groups  (e.g.,  DSEEP,  FEAT,  and  SCM),  especially  with 
regards  to  scenario  development. 

A  major  finding  of  MSG-086  (besides  the  detailed  documentation  of  simulation  interoperability  issues) 
is  that  simulation  interoperability  is  not  primarily  a  technical  issue,  but  that  simulation  interoperability  needs 
to  be  addressed  in  a  holistic  way  along  the  whole  simulation  environment  engineering  process.  Achieving 
simulation  interoperability  requires  efforts  and  standardization  on  the  technical,  the  syntactic,  the  semantic, 
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and  the  pragmatic  level.  Focusing  only  on  standards  for  distributed  systems  or  reuse  of  components  will  not 
lead  to  simulation  interoperability  on  higher  levels. 

Based  on  these  conclusions,  MSG-086  worked  out  proposals  for  future  activities  within  the  NMSG  and 
for  cooperative  actions  with  S1SO.  One  of  the  most  promising  approaches  towards  improving  simulation 
interoperability  is  a  service-oriented  approach,  commonly  referred  to  as  ‘"M&S  as  a  Service”.  It  is 
recommended  to  continue  initial  work  done  by  MSG-131  (“Modelling  and  Simulation  as  a  Service: 
New  Concepts  and  Service-Oriented  Architectures”)  and  to  investigate  the  potential  of  M&S  as  a  Service 
by  a  dedicated  Task  Group.  Regarding  cooperative  action  with  SISO  the  recommendation  is  to  transform 
the  “Guideline  on  Scenario  Development  for  (Distributed)  Simulation  Environments”  into  an  official 
SISO  standard. 
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Guide  en  vue  du  developpement  de  scenario 
dans  le  cadre  de  simulation  distribute 

(STO-TR-MSG-086-Part-II) 

Synthese 

Puisque  le  questionnaire  d’ analyse  des  lacunes  de  M&S  du  MORS  du  NMSG  a  determine  que  le  manque 
d’interoperabilite  de  la  simulation  constituait  la  lacune  prioritaire  a  combler  en  matiere  de  capacite, 
une  equipe  exploratoire  (ET-027)  a  ete  constitute  au  sein  du  NMSG  pour  etudier  l’interoperabilite  de  la 
simulation.  L’ET-027  a  identifie  63  problemes  qui  limitent  fortement  l’interoperabilite  de  la  simulation. 
Le  MSG-086  « Interoperabilite  de  la  simulation  »  a  ete  cree  en  2010  sur  la  base  des  conclusions  de 
PET-027  ;  sa  mission  est  d’analyser  les  problemes  d’interoperabilite  mis  au  jour  par  l’ET-027.  Cette  analyse 
devait  servir  a  recommander  et  creer  des  prototypes  d’applicatifs  qui  ameliorent  les  processus  de  creation  et 
realisation  de  simulation  distribuee  (DSEEP,  Distributed  Simulation  Engineering  and  Execution  Process) 
[DSEEP]  afm  d’attenuer  ou  eviter  les  problemes  d’interoperabilite  identifies.  Au  total,  le  MSG-086  identifie 
et  decrit  46  problemes  d’interoperabilite  et  les  classe  en  neuf  groupes.  Tous  les  problemes  sont  documentes 
selon  le  meme  schema  ainsi  que  leur  lien  avec  les  normes  de  M&S  associees. 

Les  normes  actuelles  relatives  aux  environnements  de  simulation  distribuee  se  concentrent  principalement 
sur  les  niveaux  technique,  syntaxique  et  (dans  une  certaine  mesure)  semantique  de  l’interoperabilite. 
Pour  repondre  aux  besoins  futurs,  notamment  en  termes  de  qualite  et  de  reduction  des  delais  et  des  couts, 
l’interoperabilite  de  la  simulation  doit  avoir  lieu  a  des  niveaux  plus  eleves  (autrement  dit,  aux  niveaux 
pratique,  dynamique  et  conceptuel)  de  meme  que  l’automatisation  relative  du  developpement, 
de  1’  integration  et  de  la  mise  en  oeuvre  des  environnements  de  simulation  distribuee. 

Cela  exige  une  normalisation  des  applicatifs  crees  pendant  le  developpement  d’un  environnement  de 
simulation,  a  la  suite,  par  exemple,  du  DSEEP.  Ces  produits  normalises  doivent  repondre  a  des  niveaux 
d’interoperabilite  superieurs  aux  normes  actuelles  d’interoperabilite  de  la  simulation,  qui  se  concentrent  sur 
des  niveaux  inferieurs  (autrement  dit,  les  questions  techniques,  syntaxiques  et  semantiques). 

En  partant  des  problemes  d’interoperabilite  identifies  et  de  leur  impact  sur  le  processus  d’ingenierie  de 
1’ environnement  de  simulation,  le  MSG-086  a  concentre  ses  efforts  sur  la  problematique  liee  au  «  scenario  ». 
Afm  d’ameliorer  l’interoperabilite  de  la  simulation  dans  le  contexte  du  DSEEP,  le  MSG-086  a  redige  un 
«  Guide  au  developpement  des  scenarios  dans  les  environnements  de  simulation  (distribuee) ».  Ce  guide 
augmente  le  DSEEP  relativement  a  P  elaboration  des  scenarios  et  propose  un  contenu  et  une  structure 
d’applicatif  pour  la  specification  des  scenarios. 

En  outre,  le  MSG-086  delivre  les  resultats  secondaires  et  documents  suivants  : 

•  Recommandations  de  mise  a  jour  de  l’AMSP-01  [AMSP-01]  relativement  a  l’interoperabilite  de 
la  simulation  et  au  developpement  des  scenarios. 

•  Proposition  de  mise  a  jour  du  questionnaire  d’analyse  des  lacunes  du  Sous-groupe  des  besoins 
operationnels  militaires  (MORS)  du  NMSG. 

•  Recommandations  aux  groupes  de  travail  de  la  S1SO  (par  exemple,  DSEEP,  FEAT  et  SCM), 
en  particulier  au  sujet  du  developpement  des  scenarios. 
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L’une  des  grandes  conclusions  du  MSG-086  (en  plus  de  la  documentation  detaillee  sur  les  problemes 
d’interoperabilite  de  la  simulation)  est  que  l’interoperabilite  de  la  simulation  n’est  pas  fondamentalement  une 
question  technique,  mais  qu’elle  doit  etre  abordee  de  maniere  holistique  tout  au  long  du  processus 
d’ingenierie  de  l’environnement  de  simulation.  L’interoperabilite  de  la  simulation  exige  du  travail  et  une 
normalisation  aux  niveaux  technique,  syntaxique,  semantique  et  pragmatique.  11  ne  suffit  pas  de  se  focaliser 
sur  les  normes  des  systemes  distribues  ou  sur  la  reutilisation  de  composants  pour  ameliorer  l’interoperabilite 
de  la  simulation. 

A  partir  de  ces  conclusions,  le  MSG-086  propose  des  activites  futures  au  sein  du  NMSG  et  des  actions  en 
cooperation  avec  la  S1SO.  L’une  des  approches  les  plus  prometteuses  pour  ameliorer  l’interoperabilite  de 
la  simulation  est  une  approche  axee  sur  le  service  foumi,  couramment  appelee  «  M&S  en  tant  que 
service  ».  11  est  recommande  de  poursuivre  le  travail  initial  accompli  par  le  MSG-131  («  Modelisation  et 
simulation  en  tant  que  service,  de  nouveaux  concepts  et  de  nouvelles  architectures  axees  sur  le  service  ») 
et  de  confier  a  un  groupe  de  travail  special  1’ etude  du  potentiel  de  la  M&S  en  tant  que  service.  En  ce  qui 
conceme  les  actions  en  cooperation  avec  la  S1SO,  il  est  recommande  de  transformer  le  «  Guide  au 
developpement  des  scenarios  dans  les  environnements  de  simulation  (distribues)  »  en  une  norme  officielle 
de  la  S1SO. 
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1.1  MOTIVATION 

Regardless  of  the  application  domain  -  e.g.,  training,  analysis  or  decision  support  -  scenarios  are  used  to 
specify  situations  and  conditions  to  be  represented  in  a  simulation  environment  for  the  intended  purpose  of  a 
simulation  application.  Typically  a  scenario  specification  contains  information  about  the  geographic  location, 
involved  entities,  about  the  initial  situation  and  about  pre-planned  courses  of  action  and  major  events 
happening  during  the  simulation  execution.  Therefore,  scenarios  defined  by  the  user  of  a  simulation 
environment  are  paramount  sources  of  requirements  for  the  engineers  faced  with  planning  and  setting  up  a 
simulation  environment.  As  such,  well-specified  scenarios  are  of  utmost  importance.  If  such  scenarios  are 
missing,  this  may  lead  to  various  problems  due  to  misunderstandings  when  talking  about  the  objectives  and 
scope  of  a  simulation  environment.  As  a  result,  the  conceptual  model  (and  the  subsequently  developed 
simulation  environment)  may  not  reflect  what  the  user  originally  wanted.  In  other  words,  the  simulation 
environment  does  not  fulfil  the  original  requirements  or  does  not  answer  the  questions  originally  posed. 
Therefore,  missing  or  incompletely  specified  scenarios  will  lead  to  simulation  results  that  do  not  reflect  what 
the  user  was  expecting. 

Ideally,  a  scenario  specification  should  be: 

•  Complete; 

•  Consistent;  and 

•  Understandable. 

Completeness  means  that  a  scenario  specification  has  to  contain  sufficient  information  to  enable  persons  in 
the  subsequent  process  (especially  during  development  of  the  conceptual  model)  to  use  the  scenario  in  a 
meaningful  way  and  to  extract  all  information  required  for  their  activities.  Consistency  refers  to  the  internal 
correctness  of  a  scenario  specification  (e.g.,  no  unit  belongs  to  more  than  one  party;  initial  positions  of  all 
units  are  within  the  specified  geographic  area).  Understandability  requires  that  a  scenario  specification  has  to 
be  written  and  structured  in  a  way  that  it  is  easily  accessible  by  future  users. 


1.2  PURPOSE 

The  purpose  of  this  guideline  is  to  provide  detailed  information  regarding  the  development  of  scenarios  for 
(distributed)  simulation  environments  and  the  relationship  of  the  scenario  development  process  with  the 
overarching  simulation  environment  engineering  process.  This  guideline  is  based  on  the  Distributed 
Simulation  Engineering  and  Execution  Process  (DSEEP)  [DSEEP]  and  augments  the  DSEEP  with  additional 
information  specific  to  scenario  development. 

This  guideline  gives  an  overview  of  existing  standards  and  tools  that  may  be  used  for  scenario  development. 
However,  due  to  missing  experiences  and  large  differences  between  simulation  environments  this  guideline 
does  not  recommend  specific  standards. 


1.3  SCOPE 

The  primary  scope  of  this  guideline  is  the  development  of  scenarios  in  context  of  (distributed)  simulation 
environments. 

Although  similar  in  nature,  this  guideline  does  not  explicitly  address  scenarios  used  in  live  exercises  or 
Computer-Assisted  eXercises  (CAX).  Nevertheless,  many  considerations  laid  out  in  this  guideline  are  also 
applicable  to  these  application  domains. 
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1.4  INTENDED  AUDIENCE 

The  intended  audience  of  this  guideline  includes  (but  is  not  limited  to): 

•  Primarily,  project  managers  and  simulation  engineers  which  need  to  set  up  a  simulation 
environment; 

•  Users  and  subject-matter  experts  which  define  and  specify  requirements  for  a  simulation 
environment;  and 

•  Operator  personnel  that  operates  simulation  systems  and  other  member  applications  of  a  simulation 
environment. 

This  guideline  is  not  restricted  to  a  specific  application  domain  (e.g.,  military  scenarios),  but  may  be  applied 
in  various  different  application  domains  (e.g.,  crisis  management  scenarios). 


1.5  DOCUMENT  OUTLINE 

•  As  many  problems  arise  out  of  different  interpretations  of  the  term  “scenario”,  Chapter  2  defines  the 
term  “scenario”  and  provides  related  terminology.  Afterwards,  different  types  of  scenarios  within 
different  steps  of  the  DSEEP  are  identified  and  described  in  detail. 

•  Chapter  3  presents  necessary  scenario  documentation.  Based  on  both  practical  experiences  as  well  as 
literature  research,  a  set  of  documentation  items  for  specifying  scenarios  is  presented. 

•  Chapter  4  discusses  maturity  levels  for  scenario  specifications  and  highlights  the  importance  of  formal 
scenario  specifications  (e.g.,  using  MSDL). 

•  Chapter  5  provides  an  overview  of  currently  available  standards  and  tools  for  scenario  specification. 
Features  currently  missing  in  available  standards  are  identified. 

•  Annex  A  and  B  describe  how  the  NATO  Architecture  Framework  and  Base  Object  Models  are  related  to 
scenario  specifications. 

•  Annex  C  and  D  present  two  example  scenario  specifications. 
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2.1  DEFINITION  “SCENARIO” 

The  term  “scenario”  has  many  definitions.  An  exhaustive  overview  of  definitions  for  the  term  “scenario”  is 
given  in  [MSG-053]  and  [12S-SIW-014].  The  definition  recommended  by  this  guideline  in  context  with  the 
development  and  execution  of  simulation  environments  is  the  following: 

“A  scenario  is  a  description  of  the  hypothetical  or  real  area,  environment,  means,  objectives,  and 
events  during  a  specified  time  frame  related  to  events  of  interest.”  [MSG-053,  pp.  2-3] 

This  definition  was  proposed  by  the  NATO  Modelling  and  Simulation  Group  MSG-053  “Rapid  Scenario 
Generation  for  Simulation  Applications”  and  a  similar  definition  can  be  found  in  [NATOCOBP]. 

As  the  term  “scenario”  may  have  a  different  meaning  in  another  context  (e.g.,  CAX),  it  is  stressed  that  this 
document  is  primarily  concerned  with  scenarios  in  the  context  of  (distributed)  simulation  environments. 

Unfortunately,  as  experience  shows  again  and  again,  the  term  “scenario”  is  used  in  an  ambiguous  way, 
even  if  there  is  agreement  about  the  above  definition: 

1)  Use  of  the  term  “scenario”  in  context  with  the  first  steps  of  the  development  and  execution  process 
of  simulation  environments  (“Define  Simulation  Environment  Objectives”  (Step  1  of  the  DSEEP) 
and  “Perform  Conceptual  Analysis”  (Step  2  of  the  DSEEP),  in  particular  with  Step  2,  Activity  2.1 
(“Develop  Scenario”)  of  the  DSEEP): 

“The  purpose  of  this  activity  is  to  develop  a  functional  specification  of  the  scenario. 
Depending  on  the  needs  of  the  simulation  environment,  the  scenario  may  actually  include 
multiple  scenarios,  each  consisting  of  one  or  more  temporally  ordered  sets  of  events  and 
behaviours  (i.e.,  vignettes).”  [DSEEP,  p.  13] 

2)  Use  of  the  term  “scenario”  in  context  with  later  steps  of  the  development  and  execution  process 
of  simulation  environments  (“Develop  Simulation  Environment”  (Step  4  of  the  DSEEP)  and 
“Plan,  Integrate  and  Test  Simulation  Environment”  (Step  5  of  the  DSEEP),  in  particular  with  Step  4, 
Activity  4.2  (“Establish  Simulation  Environment  Agreements”)  of  the  DSEEP): 

“ Once  all  authoritative  data  sources  that  will  be  used  in  support  of  the  simulation 
environment  have  been  identified,  the  actual  data  stores  are  used  to  transition  the 
functional  description  of  the  scenario  (developed  in  Step  2;  see  Figure  4)  to  an  executable 
scenario  instance  (or  set  of  instances)”  [DSEEP,  p.  26] 

To  clarify  the  scenario  terminology,  the  following  sections  describe  the  scenario  development  process  and 
the  three  different  types  of  scenarios  that  are  developed  during  this  process. 


2.2  SCENARIO  DEVELOPMENT  PROCESS 

During  the  planning  and  design  process  of  a  simulation  environment,  the  scenario  specification  is 
continuously  refined  and  augmented  with  additional  information.  In  order  to  establish  a  clear  understanding 
of  scenarios  and  their  role  within  distributed  simulation  environments,  a  three-step  scenario  development 
process  is  proposed.  As  shown  in  Figure  2-1  three  types  of  scenarios  are  distinguished: 

•  Operational  scenarios; 
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•  Conceptual  scenarios;  and 

•  Executable  scenarios. 


Figure  2-1:  Types  of  Scenarios  in  the  Simulation  Environment  Engineering  Process. 


Table  2-1  gives  an  overview  of  DSEEP  activities  in  which  the  three  types  of  scenarios  are  created  and  which 
persons  are  (mainly)  involved.  Detailed  descriptions  on  each  type  of  scenario  are  given  in  the  following  sub¬ 
sections. 


Table  2-1 :  Types  of  Scenarios  and  Their  Relation  to  DSEEP  Activities. 


Type  of  Scenario 

DSEEP  Activities 

Involved  Persons 

Operational  scenario 

Activity  1 . 1  “Identify  User/Sponsor  Needs”  and 
Activity  1.2  “Develop  Objectives” 

User/sponsor.  Subject- 
Matter  Experts  (SMEs) 

ConcepUial  scenario 

Activity  2. 1  “Develop  scenario” 

M&S  experts  (assisted  by 
user  and  SMEs) 

Executable  scenario 

Activity  4.2  “Establish  Simulation  Environment 
Agreements” 

M&S  experts,  system 
operators 

Within  this  guideline  the  terms  “user”  and  “sponsor”  are  used  in  the  sense  of  the  DSEEP: 

“The  person,  agency >,  or  organization  who  determines  the  need  and  scope  of  a  distributed  simulation 
exercise  or  e\,ent,  and  establishes  the  funding  and  other  required  resources.  The  user/sponsor  also 
approves  the  participants,  objectives,  requirements,  and  specifications.  The  user/sponsor  appoints  the 
simulation  environment  manager  and  verification,  validation,  and  accreditation/acceptance  (W&A) 
agents.  ”  [DSEEP.  p.  4] 
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2.2.1  Operational  Scenario 

Operational  scenarios  are  authoritative  descriptions  by  Subject-Matter  Experts  (SMEs)  -  using  their'  domain- 
specific  terminology  -  of  those  parts  of  the  real  world  that  need  to  be  represented  in  the  simulation 
environment.  Operational  scenarios  are  required  to  specify  what  has  to  be  represented  in  a  simulation 
environment  to  fulfil  the  user’s  needs  and  objectives.  Authoritative  means  that  operational  scenarios  are 
binding  requirements  for  the  development  of  a  specific  simulation  environment. 

Operational  scenarios  have  to  be  provided  by  the  user  or  sponsor  (probably  assisted  by  subject-matter 
experts)  at  the  very  beginning  of  the  planning  process  of  a  simulation  environment  (DSEEP  Step  1 
“Define  Simulation  Environment  Objectives”).  Operational  scenarios  are  of  highest  importance  as  they  are 
authoritative  sources  of  requirements  for  the  intended  simulation  environment.  Jointly  with  further 
requirements  (e.g.,  regarding  cost,  schedule  or  validity)  they  provide  the  frame  for  the  M&S  experts  which 
are  designing  and  engineering  the  simulation  environment. 

As  illustrated  in  Figure  2-2.  the  simulation  application  space  (i.e.,  the  totality  of  possible  simulation 
applications)  may  be  structured  using  the  following  5-dimensional  structure  (see  [NMSG-024.  Chapter  3]): 

1)  Simulation  application  mode  (education,  training,  exercise,  research  and  development, 
experimentation,  execution  support). 

2)  Capability/Activity  (defence  analysis  and  planning,  operational  analysis  and  planning,  conducting 
operations). 

3)  Military  level  (technical  (systems),  tactical,  operational,  strategic,  political). 

4)  Kurd  of  mission  (Article  5  (missions  related  to  war).  Non-Article  5  (missions  related  to  operations 
other  than  war)). 

5)  Staff  involved  (CJ1,  CJ2  (staff  taking  care  of  enemy  forces),  CJ3  (staff  taking  care  of  own  forces), 
CJ4  (logistics  staff),  CJ9.  etc.). 


Description  of  scenarios  on  the  basis 
of  an  operational  planning  guide  or  I 

scenario  development  process  j 


Figure  2-2:  Role  of  Operational  Scenarios  in  the  Early  Steps 
of  a  Simulation  Environment  Engineering  Process. 
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A  single  instance  of  the  simulation  application  space  is  denoted  as  “Application  domain”.  An  example  for  an 
instance  of  the  application  space  (thus  for  an  application  domain)  could  be: 

•  For  training; 

•  In  defence  analysis/planning; 

•  On  the  operational  level; 

•  In  context  with  a  peace  support  operation  (Non-Article  5);  and 

•  For  the  CJ4  (Logistics). 

Thus,  specifying  the  application  domain  forces  the  user  to  answer  the  question  “For  which  purpose  is  a 
simulation  environment  supposed  to  be  used?”  Based  on  the  specification  of  the  application  domain,  suitable 
operational  scenarios  have  to  be  selected  (if  available)  or  developed.  In  practice,  the  user  often  specifies  an 
operational  scenario  before  defining  all  objectives  and  questions.  In  this  case,  it  is  important  that  the 
application  domain  is  aligned  with  the  given  operational  scenarios.  The  alignment  process  may  be  iterative, 
i.e.,  based  on  a  given  operation  scenario  the  application  domain  and  the  questions  to  be  answered  are 
specified,  these  questions  may  then  be  used  to  refine  the  operational  scenarios. 

As  operational  scenarios  are  authoritative  sources  of  requirements  for  the  subsequent  development  of  the 
simulation  environment  they  provide: 

•  A  description  of  a  real  or  fictitious  piece  of  the  world  of  interest,  including  the  initial  state  and 
desired  end  state; 

•  The  effects  considered  to  be  necessary  for  a  transition  from  the  initial  state  to  the  desired  end  state; 

•  The  required  tasks  to  accomplish  these  effects; 

•  The  required  capabilities  to  enable  these  tasks;  and 

•  The  required  force  packages  to  assure  these  capabilities. 

It  has  to  be  kept  in  mind  that  descriptions  of  operational  scenarios  differ  depending  on  the  level  of  the 
scenario  (e.g.,  political,  strategic,  operational,  tactical).  For  multi-level  simulation  environments  a  consistent 
hierarchy  of  operational  scenarios  is  mandatory. 

Operational  scenarios  are  described  in  terms  the  user  is  familiar  with  and  may  be  documented  in  any  format. 
Often  a  combination  of  a  graphical  and  a  textual  description  is  chosen.  Ideally  -  to  capture  all  aspects  of 
relevance  -  the  descriptions  of  such  operational  scenarios  should  follow  an  operational  planning  process  or 
scenario  development  process  as  described  in  [NMSG-024],  [NATO  COPD],  For  each  selected  or  developed 
operational  scenario  it  has  to  be  described  how  it  is  related  to  the  application  domain  and  how  it  supports  the 
original  objectives  and  needs  of  this  application  domain. 

Each  scenario  description  could  (depending  on  the  application  domain)  embrace  all  or  parts  of  the  following 
information: 

•  Reason  for  the  creation  and  use  of  the  scenario,  objectives  of  the  scenario,  relation  to  the  application 
domain; 

•  Relation  to  higher  and/or  lower  level  scenarios  (hierarchy  of  scenarios!); 

•  Historical  context,  road  to  war/operations; 

•  PMESII  (political,  military,  economic,  social  [cultural,  humanitarian,  legal],  infrastructure, 
information); 

•  Types  and  numbers  of  major  entities  (units,  personnel,  equipment,  resources  [facilities,  logistics, 
associated  sustainment])  that  must  be  represented  within  the  simulation  environment; 
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•  A  description  of  the  characteristics,  capabilities,  behaviour,  and  relationships  between  these  major 
entities  over  time; 

•  Missions  (initial  state  and  desired  end  state),  operations,  tasks,  and  associated  effects  of  these 
entities  over  time; 

•  Sequence  of  actions  or  occurrences  relevant  to  the  objectives,  TOEL  (Time-Ordered  Event  List 
[->  events  can  change  the  environment  dynamically]),  MEL/MIL  (Main  Event  List  /  Main  Incident 
List); 

•  Playbook,  game  plan  (plans,  orders,  associated  behaviours); 

•  Constraints  (doctrines,  rules  of  engagement,  orders,  control  measures); 

•  A  specification  of  relevant  environmental  conditions  (terrain  [urban  terrain  versus  natural  area,  type 
of  terrain,  positions  for  physical  objects],  ocean,  space,  atmosphere/weather,  day/night,  climate,  etc.) 
that  impact  or  are  impacted  by  entities  in  the  simulation  environment;  and 

•  Specific  geographic  regions  (areas  of  operations,  areas  of  interest,  geographical  locations  of  objects 
of  interest). 

As  far  as  possible  these  information  should  be  based  on  authoritative  sources  and  documents. 

A  sub-step  between  the  “Operational  Scenarios”  and  the  “Simulation  Environment  Requirements”  is  the 
“Problem  Space”  (see  Figure  2-2).  The  problem  space  defines  which  (or  which  parts)  of  the  operational 
scenarios  (possibly  simplified,  adapted,  or  extended)  have  to  be  represented  in  the  simulation  environment. 
While  the  operational  scenarios  are  defined  by  the  user,  the  problem  space  is  defined  by  M&S  experts 
(in  collaboration  and  interaction  with  SMEs).  The  problem  space,  together  with  additional  requirements 
derived  from  the  objectives  and  needs  of  the  intended  application  domain,  forms  the  cornerstones  for  the 
derivation  of  the  requirements  for  the  development  of  the  conceptual  model  for  a  simulation  environment. 

Thus,  operational  scenarios  are  characterized  by  the  following  aspects: 

•  They  answer  the  question  “What  has  to  be  represented  in  a  simulation  environment?”; 

•  They  are  described  by  SMEs  using  domain-specific  terminology  and  guidelines; 

•  They  are  human  readable; 

•  They  are  related  to  a  certain  application  domain  (=  instance  of  the  application  space);  and 

•  They  are  a  basic  pre-requisite  and  authoritative  source  for  the  definition  of  the  problem  space, 
thus  for  the  development  of  the  conceptual  model  of  a  simulation  environment  (DSEEP  Activity 
2.1). 

2.2.2  Conceptual  Scenario 

The  operational  scenarios  provide  a  coarse  description  of  the  intended  situation  and  its  dynamics,  but  usually 
do  not  contain  enough  information  for  deriving  a  conceptual  model  and  designing  a  simulation  environment. 
For  development  of  a  conceptual  model  as  fundamental  pre-condition  for  the  development  of  a  simulation 
environment  the  operational  scenarios  need  to  be  refined  and  augmented  with  additional  information. 

This  is  the  focus  of  DSEEP  Activity  2.1  (“Develop  Scenario”)  which  will  most  often  be  carried  out  by  M&S 
experts  (lead)  which  are  assisted  by  the  user  and  further  subject-matter  experts.  The  resulting  “conceptual 
scenarios”  provide  a  detailed  specification  of  the  piece  of  the  world  to  be  simulated  and  should  provide  all 
necessary  information  for  persons  which  are  involved  in  later  steps  of  the  simulation  environment 
engineering  process. 
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Although  the  conceptual  scenarios  are  primarily  developed  by  M&S  experts,  a  tight  integration  of  the  original 
user  and  subject-matter  experts  is  usually  necessary.  This  helps  to  reduce  misunderstandings  and  ensures  that 
the  right  conceptual  scenarios  are  derived  from  the  given  operational  scenarios. 

Like  the  operational  scenarios  also  the  conceptual  scenarios  are  specified  in  terms  the  user  is  familiar  with. 
Y et,  as  the  development  of  the  conceptual  scenarios  is  led  and  coordinated  by  M&S  experts  this  transfer  of 
responsibility  is  also  reflected  in  the  scenario  specification.  Especially,  the  M&S  experts  should  aim  for  a 
more  structured  specification  of  conceptual  scenarios  and  should  ensure  that  all  information  required  for 
setting  up  a  simulation  environment  is  specified.  This  may  be  supported  by  enforcing  a  more  precise  use  of 
simulation-related  terms.  Also  the  use  of  specialized  tools  or  methodologies  for  scenario  specification  should 
be  considered. 

2.2.2. 1  Relation  of  Conceptual  Scenario  and  Operational  Scenario 

The  totality  of  operational  scenarios  to  be  represented  in  a  simulation  environment  determines  what  is  also 
known  as  the  “mission  space”.  Based  on  the  operational  scenarios  (or  the  “mission  space”),  the  conceptual 
scenarios  are  derived  (as  abstractions  of  the  underlying  operational  scenarios).  The  conceptual  scenarios 
provide  a  specification  of  that  piece  of  the  real  world  which  is  reflected  by  the  mission  space  (respectively 
the  operational  scenarios). 

2.2.2.2  Relation  of  Conceptual  Scenario  and  Conceptual  Model 

The  DSEEP  treats  the  development  of  conceptual  scenarios  in  Activity  2. 1  “Develop  Scenario”.  This  activity 
is  intimately  connected  to  Activity  2.2  “Develop  Conceptual  Model”,  and  as  described  by  the  DSEEP  the 
conceptual  scenario  and  the  conceptual  model  may  be  developed  in  parallel.  The  conceptual  model  describes 
the  entities  and  their  static  and  dynamic  relationships. 

For  this  purpose,  the  conceptual  model  may  define  entity  classes  and  their  attributes  (much  like  classes  are 
defined  in  any  object-oriented  programming  language),  for  example: 

Entity  class  “Helicopter  H-l” 

Attributes:  remainingFuel  in  litres,  ammunition  in  rounds 


Following  an  object-oriented  view,  conceptual  scenarios  may  reference  and  instantiate  these  entity  classes 
(see  Figure  2-3).  It  is  important  to  note  that  other  “views”  (e.g.,  ontology-related  approaches  [Mojtahed2005, 
Mojtahed2008],  architecture  approaches  using  NAF)  exist  and  may  be  more  appropriate  for  specifying 
certain  conceptual  models.  The  object-oriented  view  is  chosen  here  only  as  an  example. 
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Figure  2-3:  Relation  of  Conceptual  Scenario  and  Conceptual  Model 
Regarding  Entity  Classes  and  Entities  (Top)  and  Example  (Bottom). 

A  conceptual  scenario  may  contain  multiple  entities  of  the  same  entity  class.  For  consistency  and 
completeness  it  is  important  that  the  conceptual  scenario  and  the  conceptual  model  are  aligned.  This  requires 
at  least  that  each  entity  of  the  conceptual  scenario  must  be  associated  with  an  entity  class  defined  hi  the 
conceptual  model.  Ensuring  this  alignment  is  part  of  the  verification  and  validation  activities  accompanying 
the  original  simulation  environment  development  process. 

It  is  important  to  identify  all  attributes  (or  parameters)  and  to  specify  them  unambiguously  during 
development  of  conceptual  scenarios  (e.g..  an  attribute  for  temperature  expressed  hi  °F  or  °C,  or  wind  speed 
expressed  hi  km/h  or  111/s).  hi  addition,  where  applicable,  the  definition  of  valid  value  ranges  for  attributes 
can  help  avoid  misunderstanding  (e.g.,  whid  speed  has  to  be  a  positive  value). 

As  illustrated  hi  Figure  2-3.  a  conceptual  scenario  may  assign  values  to  entity  attributes.  However,  assignment 
of  attribute  values  is  not  strictly  necessary  at  this  pomt  hi  tune  and  may  be  delayed  until  specification  of 
executable  scenarios. 

2.2.3  Executable  Scenario 

Once  the  simulation  environment  is  designed  and  set  up.  the  conceptual  scenarios  have  to  be  made  available 
to  all  simulation  systems  and  other  member  applications  of  the  simulation  environment.  For  tins  purpose  the 


STO-TR-MSG-086-Part-ll 


2-7 


SCENARIOS  IN  DISTRIBUTED  SIMULATION  ENVIRONMENTS 


vW.4.^  | 

organization 


conceptual  scenaiios  need  to  be  transfonned  into  “executable  scenarios”.  This  is  the  done  in  DSEEP  Activity 
4.2  (“Establish  Simulation  Environment  Agreements”). 

An  executable  scenario  is  the  specification  of  a  specific  situation  providing  all  information  necessary  for 
preparation,  initialization  and  execution  of  a  simulation  environment.  The  transformation  front  conceptual 
scenarios  to  executable  scenarios  is  done  primarily  by  the  operator  personnel  of  the  member  applications  of 
the  simulation  environment  (possibly  assisted  by  M&S  experts  or  SMEs).  Ideally,  the  resulting  executable 
scenarios  should  be  specified  in  a  way  that  they  are  directly  accessible  by  the  member  applications  (e.g.,  as  a 
file  or  via  a  web  service). 

The  DSEEP  is  using  the  term  “executable  scenario  instance”.  For  an  expert  this  term  describes  quite  well 
what  is  meant.  However,  unfortunately  this  term  is  not  further  defined  in  the  DSEEP.  and  even  M&S  experts 
continue  to  use  just  the  term  “scenario”  in  this  context,  again  and  again  generating  confusion.  We  propose 
the  following  definition  for  “Executable  scenario”: 

An  executable  scenario  is  a  specification  of  a  specific  scenario  that  provides  all  information 
necessary  for  preparation,  initialization  and  execution  of  a  simulation  environment. 

In  order  to  get  a  simulation  environment  “ready  for  execution”,  three  basic  steps  have  to  be  carried  out: 

1)  The  entities  to  be  represented  in  the  execution  of  a  simulation  environment  have  to  be  selected 
(as  specified  in  the  executable  scenario  that  will  be  executed).  Of  course  these  entities  have  to  be 
defined  in  the  conceptual  model  of  the  simulation  environment  that  was  derived  from  given 
operational  scenarios  as  described  above. 

2)  These  entities  have  to  be  allocated  to  individual  federates  within  a  simulation  environment 
(see  Figure  2-4).  This  decision  determines  which  federate  executes  which  entities. 

3)  Certain  initial  values  have  to  be  assigned  to  the  attributes  of  these  entities  (see  Figure  2-5). 


Entities  to  be  represented 
in  simulation  environment 


Figure  2-4:  Allocation  of  Entities  to  Federates  of  a  Simulation  Environment 
for  Different  Executions  of  the  Simulation  Environment. 
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Figure  2-5:  Allocation  of  Values  to  Attributes  of  Entities  to  be  Represented  by 
the  Different  Federates  for  Different  Simulation  Environment  Executions. 

Thus,  in  tliis  context  always  the  term  “executable  scenario”  should  be  used.  An  executable  scenario  is 
characterized  by  the  following  aspects: 

•  It  answers  the  question  “What  (which  specific  entities  with  which  specific  characteristics)  has  to  be 
represented  hi  a  specific  federate  of  a  specific  simulation  environment  execution?”. 

•  It  represents  a  sub-space  of  the  problem  space,  which  means  parts  of  the  conceptual  model  of  the 
simulation  environment. 

•  It  is  a  basic  pre-requisite  for  the  execution  of  a  simulation  environment  (DSEEP  Activity  4.2). 
Therefore,  it  must  be  possible  to  derive  specific  configuration  files  and  settings  from  an  executable 
scenario  to  configure  and  initialize  each  system  of  a  simulation  environment. 

•  It  is  developed  by  mainly  by  operator  personnel  (probably  assisted  by  M&S  experts)  and  described 
using  technical  terminology  and  guidelines. 

•  Ideally  it  should  be  machine-readable  and  re-useable  (e.g..  using  a  specific  XML  schema). 
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2.3  AUXILIARY  TERMS 

2.3.1  Vignettes 

In  order  to  structure  scenario  specifications  and  to  allow  more  flexible  reuse  of  dedicated  parts  of  a  scenario, 
the  term  “vignette”  is  regularly  used.  Currently  many  definitions  exist  of  which  most  definitions  are  to  some 
degree  circular  [EU  CTF,  p.  89]  [DSEEP,  p.  13f.]  [DoD  M&S  Glossary,  p.  158],  Furthermore,  a  practical 
drawback  of  these  definitions  is  that  they  do  not  distinguish  clearly  between  a  scenario  and  a  vignette.  More  or 
less,  vignettes  are  considered  to  be  small  scenarios  or  to  be  smaller  than  a  regular  scenario.  This  leaves  much 
space  for  interpretation  and,  from  experience,  missing  clarity  and  understandability  is  a  key  factor  for 
missing  user  adoption. 

Within  this  guideline  a  vignette  is  defined  as  follows: 

A  vignette  is  a  reusable  temporally  ordered  set  of  events  and  behaviours  for  a  specific  set  of  entities. 

As  described  in  the  EU  Core  Technical  Framework  study  [EU  CTF,  p.  103ff],  vignettes  may  be  thought  of 
as  small,  ideally  self-contained  parts  of  a  scenario. 

2.3.2  Scenario  Variants 

For  purposes  of  experimental  design  a  scenario  is  often  analysed  and  executed  in  different  variants. 
We  propose  the  following  definition  in  this  context: 

A  scenario  variant  is  a  scenario  which  is  derived  from  another  scenario  by  variation  of  isolated 
parameters  for  purposes  of  experimental  design  (e.g.,  different  units  but  otherwise  no  changes). 

Scenario  variants  may  be  specified  for  all  three  types  of  scenarios,  although  they  are  most  common  in 
context  of  executable  scenarios.  Table  2-2  illustrates  an  example  for  usage  of  scenario  variants  during  the 
scenario  development  process. 


Table  2-2:  Example  of  Scenario  Variants. 


Conceptual  Scenario 
“Air  Defence” 

Executable  Scenarios 

Unit 

“Enemy  Helicopter” 

Base  Variant 

Variant  1:  Low 

Altitude  Approach 

Variant  2:  High 
Altitude  Approach 

Attribute 
“Height :  Metres” 

Height  =  500 

Height  =  50 

Height  =  2300 

Attribute 

“Remaining  Fuel :  Litres” 

Remaining  Fuel  =  1000 

Remaining  Fuel  =  1 000 

Remaining  Fuel  =  1000 

Attribute 

“Ammunition  :  Rounds” 

Ammunition  =  200 

Ammunition  =  200 

Ammunition  =  200 

2.3.3  MEL/MIL 

A  further  term  commonly  used  in  context  of  executable  scenarios  used  for  training  and  exercise  purposes  is 
“Main  Events  List”  or  “Main  Incidents  List”  (MEL/MIL).  In  this  terminology,  events  are  major  occurrences 
or  a  sequence  of  related  incidents,  which  are  actions  or  situations  that  provide  greater  clarity  to  an  event 
[Cayirci2010].  The  only  publicly  available  definition  is  the  following: 
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“Master  scenario  events  list: 

A  chronological  list  that  supplements  the  exercise  scenario  with  event  synopses;  expected  participant 
responses;  capabilities,  tasks,  and  objectives  to  be  addressed;  and  responsible  personnel.  It  includes 
specific  scenario  events  (or  injects)  that  prompt  players  to  implement  the  plans,  policies,  and 
procedures  that  require  testing  during  the  exercise,  as  identified  in  the  capabilities-based  planning 
process.  It  also  records  the  methods  that  will  be  used  to  provide  the  injects  (i.e.,>  phone  call, 
facsimile,  radio  call,  e-mail).  ”  [DoD  M&S  Glossary,  p.  121] 

Such  event  lists  define  courses  of  action  within  a  surrounding  situation.  Therefore,  they  may  be  used 
similarly  as  vignettes  to  specify  dedicated  parts  of  a  scenario  in  a  reusable  way. 
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Chapter  3  -  CONTENT  OF  A  SCENARIO 


Following  tlie  scenario  definition  given  above  the  content  of  a  scenario  specification  consists  of  three  parts: 

•  Initial  state; 

•  Course  of  events;  and 

•  Termination  conditions. 

As  these  contents  can  be  part  of  all  three  types  of  scenarios  (operational  scenarios,  concepmal  scenarios  and 
executable  scenarios),  we  do  not  distinguish  between  these  three  types  of  scenarios  in  this  section  unless 
explicitly  noted  otherwise.  As  illustrated  in  Figure  3-1,  the  content  is  continuously  refined  and  augmented 
with  additional  information  (e.g..  regarding  the  actual  systems  used  for  executing  a  scenario). 


Figure  3-1 :  Refinement  and  Extension  of  the  Content  of  a 
Scenario  Along  the  Scenario  Development  Process. 


3.1  PRELIMINARY  REMARKS 

Scenarios  may  be  described  on  very  different  levels  (e.g..  scenarios  on  the  pohtical  level,  scenarios  on  the 
sttategic  level,  scenarios  on  the  tactical  level).  Ideally  there  should  be  a  consistent  hierarchy  of  scenarios 
from  the  political  level  down  to  the  technical  level.  For  example,  a  scenario  on  the  strategic  level  should  be 
derived  from  a  political  level  scenario  on  top  of  it;  a  scenario  on  a  tactical  level  should  be  derived  from  a 
scenario  on  a  strategic  level,  and  so  on.  Depending  on  the  purpose  of  a  simulation  environment  scenarios  at  a 
suitable  level  have  to  be  selected  and  provided  by  the  user.  As  many  content  items  of  a  scenario  description 
are  the  same  for  scenarios  on  all  levels,  we  do  not  distinguish  between  scenarios  of  different  levels  in  the 
following  sub-sections,  but  present  generic  content  items  which  are  required  hr  almost  all  scenario 
descriptions. 

Furthermore,  as  the  operational  scenario  is  defined  by  the  user,  it  is  usually  described  hr  a  way  (regarding 
terminology  and  presentation)  the  user  is  familiar  with.  As  the  user  usually  is  not  an  M&S  expert,  operational 
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scenarios  may  contain  other  or  much  more  information  than  proposed  in  the  following  sections.  During  the 
process  of  transforming  operational  scenarios  into  conceptual  scenarios,  it  is  a  major  task  of  the  M&S 
experts  to  structure  the  existing  operational  scenario  description,  to  add  missing  information,  and  to  strip  off 
too  detailed  information.  Y et,  the  following  proposed  content  items  for  a  scenario  description  may  also  serve 
well  for  describing  operational  scenarios. 


3.2  INITIAL  STATE 

The  initial  state  of  a  scenario  defines  the  situation  at  the  beginning  of  the  scenario  timeline. 
Therefore,  the  initial  state  typically  contains  information  regarding  the  following  aspects: 

1 )  Obj  ects  and  units ; 

2)  Forces  and  force  structure; 

3)  Geography; 

4)  Date/time; 

5)  Surrounding  conditions;  and 

6)  Rules  of  engagement. 

The  mentioned  set  of  information  items  for  describing  the  initial  state  of  a  scenario  is  suitable  for  a  wide 
range  of  (military)  scenarios.  Nevertheless,  specific  scenarios  may  require  more  or  other  information  items. 
Especially  the  presented  set  of  information  items  is  suited  for  scenarios  which  are  directly  involving  forces 
and  units.  It  is,  for  example,  less  suited  for  describing  scenarios  in  context  of  cyberwar. 

All  information  items  are  described  in  more  detail  in  the  following  sub-sections. 

3.2.1  Objects  and  Units 

Enumeration  and  description  of  all  objects  and  units  of  this  scenario. 

The  purpose  of  this  information  item  is  to  describe  which  units  and  objects  take  part  in  the  scenario. 
It  is  particularly  important  to  describe  for  each  unit  and  each  object  why  its  participation  in  the  scenario  is 
necessary.  It  is  necessary  here  to  see  the  issue  in  connection  with  the  requirements  and  justify  the 
participation  of  the  units  and  objects.  In  turn,  the  question  should  also  be  answered:  What  would  be  the 
consequence  if  a  specific  unit  or  object  was  not  part  of  the  scenario? 

Every  unit  and  object  should  be  described  by  a  common  pattern  (see  Table  3-1  for  an  example). 
The  JC3IEDM  [JC3IEDM]  describes  in  great  detail  which  information  is  necessary  (at  least  from  an 
operational  point  of  view)  to  describe  an  object,  a  unit,  their  states,  attributes  and  capabilities. 
Therefore,  the  JC3IEDM  may  be  taken  as  a  starting  point  for  deriving  such  a  common  documentation 
pattern. 
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Table  3-1:  Example  Information  Set  for  Describing  Units  and  Objects. 


Information 

Description 

Identifier 

Every  unit  and  object  should  have  an  unambiguous  identifier. 

Description 

The  unit  or  object  has  to  be  described.  If  possible  (or  necessary)  suitable  sources  or 
references  should  be  given. 

Number 

The  numbers  in  which  the  units  and  objects  are  present  in  the  scenarios  have  to  be 
determined. 

Capabilities 

All  capabilities  of  the  units  and  objects  that  are  relevant  for  the  scenario  have  to  be 
described.  It  has  to  be  justified  with  a  view  to  the  objectives  of  the  simulation 
environment  and  the  target  values  and  requirements  why  a  specific  capability  is 
important. 

Behaviour 

In  what  way(s)  do  the  units  act?  Do  alternative  behaviours  exist? 

States 

Which  states  (e.g.,  mobile,  partly  mobile,  degree  of  damage)  have  to  be  distinguished 
concerning  the  units  and  objects? 

Attributes 

For  each  object  and  unit  all  attributes  have  to  be  identified  that  are  required  in  context 
of  the  current  scenario.  If  possible,  valid  value  ranges  for  all  attributes  should  be 
specified. 

An  important  remark  is  that  all  relevant  units  and  objects  of  a  scenario  have  to  be  described.  In  turn, 
a  scenario  must  not  contain  units  or  objects  that  are  not  described  here. 

3.2.2  Forces  and  Force  Structure 

Definition  of  forces  and  force  structures,  as  well  as  definition  of  relationships  of  objects  and  assignment  of 
units  to  forces.  Also,  command  and  control  hierarchies  may  need  to  be  specified. 

This  information  is  also  known  as  Order  of  Battle  (ORBAT): 

“The  identification,  strength,  command  structure,  and  disposition  of  the  personnel,  units,  and 
equipment  of  any  military  force.”  [AAP-06] 


3.2.3  Geography 

The  purpose  of  this  information  item  is  to  describe  the  geographic  requirements  for  a  scenario: 

1)  Area  of  Interest:  Specification  of  the  area  of  interest  of  this  scenario  (e.g.,  as  rectangular  bounding 
box); 

2)  Special  Requirements:  Requirements  regarding  buildings  (e.g.,  real  buildings  or  geotypical 
buildings),  vegetation,  roads,  ditches;  and 

3)  Environmental  Conditions:  Specification  of  all  environmental  conditions  which  are  of  interest 
within  this  scenario  (e.g.,  day/night/dawn,  rain/fog/snow/dust). 

Again,  the  question  has  to  be  answered:  Why  are  certain  requirements  necessary?  All  requirements  must  be 
derived  from  the  objectives  of  the  simulation  environment. 
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3.2.4  Date/Time 

Specification  of  date  and  time  of  the  beginning  of  the  scenario. 

3.2.5  Surrounding  Conditions 

The  surrounding  conditions  provide  an  overview  of  all  scenario-related  information  and  are  described 
according  to  the  PMES11  approach: 

1 )  Political  situation; 

2)  Military  situation; 

3)  Economic  situation; 

4)  Social  situation  /  Cultural  aspects; 

5)  Information;  and 

6)  Infrastructure. 

This  information  item  is  especially  important  if  real  operators  are  integrated  into  the  simulation  environment 
(operating  either  virtual  or  live  systems).  Unless  the  behaviour  of  the  real  operators  is  completely  determined 
a  priori,  the  surrounding  conditions  may  affect  the  actions  of  a  real  operator  (e.g.,  whether  a  crowd  is 
considered  to  be  harmful  or  not,  how  to  respond  to  enemy  behaviour). 

Especially  if  real  operators  are  involved,  it  is  important  to  stress  that  executable  scenarios  are  not  only 
specific  files  for  initializing  constructive  simulations  but  may  also  be  explanations,  MEL/MIL,  or  story 
boards  to  “initialize”  humans  (e.g.,  personnel  operating  virtual  systems). 

3.2.6  Rules  of  Engagement 

A  clear  definition  of  rules  of  engagement  is  necessary  to  ensure  the  correct  (i.e.,  intended)  behaviour  of  all 
participating  personnel  operating  live  and  virtual  systems  as  well  as  participating  constructive  systems. 


3.3  COURSE  OF  EVENTS 

Besides  a  specification  of  the  initial  state  a  typical  scenario  specification  includes  pre-planned  events 
happening  at  a  specific  time.  Such  events  are  usually  triggering  some  kind  of  reaction,  either  of  a 
participating  simulation  system  or  a  trainee  within  the  simulation  environment. 

We  propose  to  distinguish  the  following  types  of  events: 

1)  Communication  events; 

2)  Interaction  events; 

3)  State  change  events;  and 

4)  Environmental  events. 

Each  event  (whether  triggered  at  a  pre-planned  point  in  time  relative  to  the  starting  time  of  the  scenario 
or  triggered  by  some  condition)  injects  a  specific  influence  into  the  scenario.  Typically,  events 
(e.g.,  communication  events  like  orders  or  interaction  events  like  direct  fire)  are  used  to  generate  a  specific 
situation  onto  which  the  participating  member  applications  (live,  virtual  or  constructive)  have  to  react  in  a 
certain  way.  Intended  reactions  of  the  systems  may  be  very  different  and  depend  heavily  on  the  purpose 
of  the  simulation  enviromnent. 
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In  general,  the  course  of  events  of  a  scenario  is  defined  by  a  set  of  events  and  corresponds  to  the  Main 
Events  List  (MEL)  used  for  training  and  exercise  purposes. 

The  following  sub-sections  describe  the  four  event  types  in  more  detail. 

3.3.1  Communication  Events 

Communication  events  include  all  type  of  scenario-related  communication  (e.g.,  reconnaissance  reports, 
orders).  The  sender  of  a  communication  may  either  be  a  participant  of  the  simulation  environment  itself 
(e.g.,  another  simulation  system)  or  communication  may  be  injected  by  exercise  control  (e.g.,  provision  of 
fictitious  news  reports  to  operator  personnel  of  a  virtual  or  live  system). 

3.3.2  Interaction  Events 

Interaction  events  define  explicitly  interactions  regarding  objects  and  units  of  the  scenario  (e.g.,  one  unit 
attacking  another  one  or  explosion  of  an  improvised  explosive  device). 

3.3.3  State  Change  Events 

State  change  events  are  similar  to  interaction  events  but  concern  only  a  single  object  or  unit  (e.g.,  collapse  of 
a  bridge  or  breakdown  of  an  armoured  vehicle  due  to  some  technical  malfunction). 

3.3.4  Environmental  Events 

Sub-types  of  state  change  events  are  enviromnental  events  which  specify  state  changes  within  the 
environment  (e.g.,  beginning  of  rain). 


3.4  TERMINATION  CONDITIONS 

Within  (distributed)  simulation  environments  conditions  should  be  defined  for  each  scenario  determining  the 
achievement  of  a  final  state  and  thus  leading  to  a  termination  of  the  simulation  run.  Although  FEDEP  and 
DSEEP  do  not  include  termination  conditions  within  their  respective  scenario  definition,  they  mention 
termination  conditions  as  one  result  of  Activity  2.1  (“Develop  Scenario”)  [FEDEP,  p.  10]  [DSEEP,  p.  14]. 

Two  typical  termination  conditions  for  a  scenario  can  be  distinguished: 

1)  A  specific  condition  is  achieved  (e.g.,  destruction  of  all  enemy  units);  and 

2)  A  pre-defined  time  is  elapsed  (e.g.,  two  hours  of  simulation  time). 

Explicitly  defining  termination  conditions  is  especially  important  for  simulation  environments  which  are 
executed  in  a  fully  automated  fashion.  Typical  examples  for  this  are  constructive  simulation  systems  used 
within  data  farming  setups. 


3.5  REUSE  IN  THE  SCENARIO  DEVELOPMENT  PROCESS 

As  mentioned,  operational  scenarios  are  specified  by  the  user.  Therefore,  the  way  to  define  and  describe 
operational  scenarios  is  usually  dominated  by  domain-specific  regulations  (e.g.,  operational  planning 
processes  in  the  military  domain).  To  avoid  interference  with  these  planning  processes,  considerations 
regarding  reuse  in  the  scenario  development  process  are  focussed  on  conceptual  scenarios  and  executable 
scenarios.  Nevertheless,  operational  scenarios  may  also  be  subject  to  reuse  and  specific  operational  scenarios 
should  be  derived  from  authoritative  sources  (e.g.,  major  scenarios  defined  in  defence  policies). 
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Focusing  on  conceptual  scenarios  and  executable  scenarios,  two  general  options  for  exploiting  reuse  in  the 
scenario  development  process  may  be  distinguished: 

1 )  Reuse  of  a  scenario  as  a  whole;  and 

2)  Reuse  of  specific  parts  of  a  scenario. 

The  first  option  requires  putting  in  place  sufficient  storage  mechanisms  as  well  as  augmenting  scenarios  with 
specific  metadata  (e.g.,  MSC-DMS  [MSC-DMS])  for  efficient  retrieval.  As  the  scenarios  are  reused  as  a 
whole,  this  option  does  not  place  any  specific  requirements  on  the  scenario  development  process  and  does 
not  impose  any  constraints  on  the  scenario  specification.  All  organizations  involved  in  planning  and 
developing  (distributed)  simulation  environments  should  aim  for  at  least  this  level  of  scenario  reuse.  Within 
this  guideline,  this  option  is  not  discussed  any  further. 

Compared  to  the  first  option,  the  second  option  promises  improved  reuse  possibilities  and  added  flexibility. 
At  the  same  time,  option  two  requires  decomposing  a  scenario  into  smaller  parts  (building  blocks)  which 
may  then  be  assembled  according  to  some  rules  to  form  a  scenario.  The  remainder  of  this  section  is 
concerned  with  exactly  this  option  and  will  discuss  how  the  different  parts  of  a  scenario  (initial  state,  course 
of  events,  termination  conditions)  may  be  split  into  components. 

An  obvious  requirement  for  reuse  of  all  kinds  is  that  the  applicability  of  existing  components  in  a  new 
context  has  to  be  thoroughly  evaluated  each  time.  This  is  also  true  for  scenario  components  and  has  always 
to  be  kept  in  mind. 

3.5.1  Components  Regarding  Initial  State  of  a  Scenario 

Almost  all  parts  of  the  initial  state  can  be  considered  as  components  which  may  be  reused  separately  in 
multiple  scenarios.  This  is  especially  true  for  lists  of  objects  and  units  as  well  as  for  information  about  forces 
and  force  structures.  Similarly,  the  rules  of  engagement  are  a  candidate  for  reuse  as  certain  areas  of  operation 
are  often  associated  with  the  same  rules  of  engagement.  Depending  on  the  level  of  detail  PMESll-related 
information  (e.g.,  storybooks,  country  books)  is  also  a  candidate  for  reuse. 

3.5.2  Components  Regarding  Course  of  Events  of  a  Scenario 

Although  the  term  “vignette”  is  often  not  clearly  distinguished  from  the  term  “scenario”,  the  basic  idea 
behind  it  is  highly  valuable.  The  basic  idea  is  to  decompose  a  scenario  into  smaller  components  and  to 
assemble  new  scenarios  from  existing  components  (cp.  Section  2.3.1). 

For  the  possibility  to  assemble  new  scenarios  from  existing  building  blocks  (i.e.,  vignettes)  and  to  achieve 
maximum  reuse  it  is  necessary  to  specify  vignettes  independently  of  scenarios.  Therefore,  a  vignette  should 
not  contain  specific  geographic  locations  or  similar  information  (cp.  [EU  CTF]). 

For  example,  a  simple  vignette  “air  refuelling  operation”  might  specify  the  rendezvous  of  a  jet  fighter  and  a 
tanker  aircraft  in  detail  without  referring  to  actual  coordinates.  Instead,  the  vignette  would  describe  positions 
relative  to  an  imaginative  starting  point.  Integrating  this  vignette  into  a  specific  scenario  would  only  require 
specification  of  the  coordinates  of  the  starting  point.  This  integration  of  a  vignette  into  a  specific  scenario  is 
done  by  introducing  “vignette  configurations”  [EU  CTF]: 

A  vignette  configuration  places  a  vignette  or  set  of  vignettes  in  a  context  of  a  specific  scenario. 

As  vignettes  describe  a  set  of  activities  in  a  generic  way  they  may  roughly  be  associated  with  classes  in 
object-oriented  programming  languages.  Assigning  actual  values  by  defining  a  vignette  configuration  may 
then  be  associated  with  creating  instances  of  a  class  (usually  called  an  “object”). 
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With  regards  to  the  example  above,  the  actual  values  needed  for  instantiating  the  vignette  are  the  actual 
coordinates  of  the  starting  point  for  the  air  refuelling  operation. 

Figure  3-2  illustrates  the  relation  of  vignettes  and  vignette  configurations  in  a  scenario.  Once  vignettes  ar  e 
defined,  multiple  vignettes  can  be  combined  and  instantiated  with  actual  values  to  form  a  specific  scenario. 


Figure  3-2:  Relationship  between  Vignettes  and  Vignette 
Configurations  for  Composing  a  Scenario. 


It  is  obvious  that  each  vignette  which  is  integrated  into  a  scenario  imposes  certain  requirements  on  the 
scenario  (e.g..  with  regards  to  the  area,  entities).  Two  examples  for  vignettes  are  an  air  refuelling  operation 
and  a  camp  patrol  task.  Both  impose  specific  requirements  on  the  scenario: 

1)  Air  Refuelling  Operation:  This  vignette  requires  certain  specific  units  to  be  defined  in  a  scenario 
(like  a  tanker  and  a  jet  fighter)  as  well  as  a  sufficiently  large  area;  and 


2)  Camp  Patrol  Task:  This  vignette  requires  a  specific  terrain  with  a  camp  for  which  the  patrol  task 
will  be  executed. 
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It  follows  immediately  that  certain  verification  activities  are  required  to  ensure  that  selected  vignettes  and  the 
remainder  of  the  scenario  are  compatible  with  each  other. 

An  important  aspect  is  that  vignettes  should  make  use  of  parameters.  Each  parameter  will  be  associated  with 
an  actual  value  during  the  process  of  integrating  the  vignette  into  a  scenario.  Examples: 

1)  Air  Refuelling  Operation:  Possible  parameters  may  be  the  starting  points  of  the  tanker  and  the  jet 
fighter  to  be  refuelled;  and 

2)  Camp  Patrol  Task:  Possible  parameters  may  be  the  units  executing  the  patrol  task  and  their  initial 
positions. 

In  general,  the  parameters  used  in  vignettes  give  scenario  developers  the  same  degree  of  freedom  as  in 
common  programming  languages  when  writing  methods.  This  includes  the  scenario  developers  decision  on 
the  degree  of  parameter  usage  for  specific  vignettes,  i.e.,  vignettes  might  be  specified  in  a  way  that 
“everything  is  parameterized”  or  vignettes  may  be  defined  in  a  way  that  “many  to  all  aspects  are  hard¬ 
coded”.  The  following  two  snippets  of  pseudo  code  show  an  example  of  a  camp  patrol  task. 


simple_campPatrolTask(unit  u) 

//  assume  that  unit  u  is  at  the  camp’s  main  gate 
While  (scenario  is  running) 

Move  south  500  metres 
Move  east  300  metres 

Endwhile 


advanced_campPatrolTask(unit  u,  waypoint  list  waypoints) 
//  assume  that  unit  u  is  at  the  camp’s  main  gate 
While  (scenario  is  running) 

For  each  waypoint  in  waypoints  do 
Move  to  waypoint 
endfor 
Endwhile 


The  respective  benefits  of  using  parameters  or  hard-coding  certain  parts  are  the  same  as  in  programming 
languages.  While  hard-coded  vignettes  are  quick  and  easy  to  create,  they  require  detailed  knowledge 
(e.g.,  about  the  camp)  and  effectively  prohibit  reuse  (e.g.,  because  the  patrol  task  is  intimately  connected  to  a 
specific  camp).  Therefore,  the  use  of  parameters  is  highly  encouraged. 

3.5.3  Components  Regarding  Termination  Conditions  of  a  Scenario 

The  reuse  of  termination  conditions  is  not  detailed  any  further  as  the  potential  benefit  of  reuse  seems  to  be 
too  small  compared  to  the  effort  for  specifying  the  termination  conditions. 


3-8 


STO-TR-MSG-086-Part-ll 


organization 


Chapter  4  -  MATURITY  LEVELS  OF  SCENARIO  SPECIFICATION 

In  order  to  assess  the  quality  of  a  scenario  specification,  this  guideline  introduces  maturity  levels.  Maturity 
levels  are  well  known  from  CMMI  (Capability  Maturity  Model  Integration)  which  provides  the  following 
definition: 

“ Maturity  level: 

Degree  of  process  improvement  across  a  predefined  set  of  process  areas  in  which  all  goals  in  the  set 
are  attained .”  [CMMI,  p.  445] 

With  regards  to  CMMI,  the  core  idea  is  to  use  maturity  levels  as  an  indicator  for  process  improvement, 
i.e.,  a  maturity  level  indicates  that  all  goals  defined  for  this  level  are  achieved.  Similarly,  maturity  levels  may 
be  used  to  indicate  the  quality  of  a  scenario  specification. 

A  4-level  maturity  model  for  scenario  specifications  is  proposed: 

•  Level  0  -  No  written  scenario  specification; 

•  Level  1  -  Non-standardized  scenario  specification; 

•  Level  2  -  Standardized  scenario  specification;  and 

•  Level  3  -  Formal  scenario  specification. 

Table  4-1  provides  an  overview  of  the  maturity  levels  of  scenario  specifications  and  typical  ways  to 
represent  scenario  specifications  on  each  maturity  level.  Detailed  descriptions  are  provided  in  the  following 
sub-sections. 


Table  4-1:  Maturity  Levels  of  Scenario  Specification. 


Maturity  Level  of  Scenario 
Specification 

Representation  of  the  Scenario  Specification 

0  -  No  written  scenario 
specification 

Thoughts  and  ideas  within  the  mind  of  the  military  user/SME;  oral 
explanation. 

1  -  Non-standardized  scenario 
specification 

Free  text  documentation. 

2  -  Standardized  scenario 
specification 

Documentation  which  is  structured  according  to  a  standard  or  agreed 
guideline  or  template. 

3  -  Formal  scenario  specification 

Formal  specification  of  a  scenario. 

4.1  LEVEL  0  -  NO  WRITTEN  SCENARIO  SPECIFICATION 

Maturity  Level  0  refers  to  the  situation  where  no  written  scenario  specification  is  available  at  all.  In  this  case 
the  scenario  is  only  available  within  the  minds  of  the  participating  persons  and  explained  and  communicated 
orally.  Obviously,  this  kind  of  (unavailable)  documentation  is  error-prone,  arbitrarily  fuzzy  and  effectively 
prevents  all  types  of  scenario  reuse.  Also,  traceability  and  understandability  are  reduced  to  a  minimum. 

For  these  reasons,  achieving  only  maturity  Level  0  is  in  almost  all  conceivable  cases  not  sufficient. 
Very  seldom  exceptions  may  be  very  small  and  focused  simulation  environments  which  are  planned  and  set 
up  by  a  single  person  (or  very  few  persons). 
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4.2  LEVEL  1  -  NON-STAND ARDIZED  SCENARIO  SPECIFICATION 

Maturity  Level  1  indicates  the  existence  of  a  scenario  specification  at  least  in  a  non-standardized  way.  In  this 
context  “non-standardized”  means  that  the  scenario  specification  is  not  created  according  to  a  generally 
accepted  standard  but  structured  according  to  the  likings  of  the  persons  participating  in  planning  and 
designing  the  simulation  environment. 

Compared  to  maturity  Level  0,  the  main  benefit  of  a  non-standardized  scenario  specification  is  the 
availability  of  a  scenario  specification  at  all.  The  existence  of  documentation  at  all  allows  basic  traceability 
of  requirements  and  improves  understandability  of  the  simulation  environment  for  directly  involved  persons 
as  well  as  third  parties. 

However,  a  non-standardized  scenario  specification  still  comes  along  with  many  problems: 

1 )  Due  to  a  missing  standardized  documentation  template,  the  familiarization  effort  for  involved  parties 
(user,  M&S  experts,  system  operators,  etc.)  is  quite  high; 

2)  Ensuring  completeness  of  the  scenario  specification  is  complicated  (due  to  missing  checklists); 

3)  Comparability  of  scenario  specifications  is  low  as  each  scenario  is  specified  differently;  and 

4)  Reuse  is  hampered  due  to  low  comparability  of  scenario  specifications  and  thus  limited  possibilities 
for  efficiently  searching  and  finding  suitable  existing  scenarios. 

Maturity  Level  1  requires  only  the  existence  of  a  written  scenario  specification  but  does  not  require  that  this 
specification  is  structured  according  to  any  specific  standard.  Therefore,  everybody  who  is  specifying  a 
scenario  may  use  a  different,  custom  structure  for  the  scenario  documentation.  The  scenario  documentation 
may  follow  available  standards  like  the  DSEEP  which  give  a  few  hints  about  the  necessary  content  of  a 
scenario  specification.  As  the  DSEEP  does  not  provide  detailed  templates  for  scenario  specification,  it  is 
sufficient  to  achieve  maturity  Levels  0  and  1,  but  is  insufficient  for  achieving  higher  maturity  levels  of 
scenario  specification. 


4.3  LEVEL  2  -  STANDARDIZED  SCENARIO  SPECIFICATION 

Maturity  Level  2  requires  the  creation  of  a  standardized  scenario  specification  and  is  a  great  step  forward 
compared  to  maturity  Levels  0  and  1.  We  deliberately  interpret  “standardized”  rather  broad  and  consider  any 
scenario  specification  to  be  standardized  if  the  standard  is  agreed  upon  beforehand  jointly  by  all  participants 
in  the  engineering  process  and  if  the  standard  is  used  across  multiple  simulation  environments.  Therefore, 
this  broad  use  of  the  term  “standardized”  includes  open  standards  and  local  standards  (as  defined  by 
[AMSP-01]). 

Open  standards  are  defined  by  AMSP-01  [AMSP-01]  as  “Specifications  that  are  developed  by  a  standards 
organization  or  a  consortium  to  which  membership  is  open,  and  are  available  to  the  public  for  developing 
compliant  products  (with  or  without  some  license  fee)”.  Examples  for  standards  organizations  are  S1SO, 
IEEE,  and  ISO.  A  key  characteristic  of  open  standards  is  their  public  availability  that  allows  broad  usage  of 
such  a  standard. 

AMSP-01  uses  the  term  “Local  standards”  to  denote  specifications  and  standards  that  are  organization- 
specific  and  usually  not  publicly  available.  Local  standards  reflect  the  fact  that  standards  are  used  by  different 
communities  at  different  levels. 

Only  by  using  a  standardized  and  ideally  open  (i.e.,  publicly  available)  standard  for  scenario  specifications, 
potential  benefits  may  be  realized.  The  main  benefits  of  a  standardized  scenario  specification  are: 
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1)  As  all  persons  involved  in  the  scenario  specification  process  are  familiar  with  the  standard  and  the 
scenario  structure  defined  by  this  standard,  initial  familiarization  efforts  are  minimized. 

2)  Following  an  analogue  reasoning,  a  standardized  structure  allows  easier  access  to  scenario 
documentation  for  all  persons  working  on  these  scenarios.  This  includes  the  M&S  experts  which  set 
up  the  simulation  environment,  the  V&V  experts  responsible  for  the  quality  management  as  well  as 
all  readers  of  the  scenario  specification  in  general. 

3)  A  precisely  defined  scenario  specification  structure  simplifies  quality  management  activities 
(like  evaluation  of  completeness  of  a  scenario  specification). 

4)  Similarly,  a  clearly  defined  scenario  specification  structure  (ideally  accompanied  by  explanatory 
texts)  simplifies  the  development  of  a  “good”  scenario  specification.  This  availability  of  such  a 
scenario  specification  structure  is  especially  important  if  scenario  specifications  have  to  be  created 
by  persons  with  few  or  zero  experience  in  this  area. 

5)  A  precisely  defined  scenario  specification  structure  is  the  necessary  prerequisite  for  the  formal 
specification  of  a  scenario. 

As  scenarios  are  decisive  sources  of  requirements  for  the  intended  simulation  environment,  the  provision  of 
at  least  a  standardized  (and  complete)  scenario  specification  is  required  for  achieving  interoperability  of 
simulation  systems  on  the  pragmatic,  dynamic  and  conceptual  level  as  defined  by  the  Levels  of  Conceptual 
Interoperability  Model  [Wang2009]. 

4.4  LEVEL  3  -  FORMAL  SCENARIO  SPECIFICATION 

Maturity  Level  3  requires  the  formal  specification  of  a  scenario.  Several  possibilities  exist  for  defining  such  a 
formal  specification.  One  of  the  most  prominent  choices,  especially  in  the  software  engineering  domain, 
is  XML  Schema  [XMLSchema],  Other  options  include  RELAX  NG  [RelaxNG],  UML  [UML]  and  OWL 
[OWL], 

The  benefits  of  a  rigorous  formal  scenario  specification  are  manifold: 

1 )  Ideally  ambiguities  are  eliminated  or  at  least  reduced  to  a  minimum. 

2)  Secondly  and  maybe  even  more  important,  automated  processing  of  scenario  specifications  and 
extensive  utilization  of  tools  is  made  possible.  This  opens  up  a  wide  range  of  possible  applications: 

a)  Automated  consistency  checks  (e.g.,  no  units  have  overlapping  positions;  no  units  are 
positioned  outside  the  specified  geographic  boundaries). 

b)  Automated  initialization  of  all  simulation  systems  and  other  member  applications 
(like,  e.g.,  computer-generated  forces)  which  are  part  of  the  simulation  environment. 
Benefits  are  a  reduced  risk  of  errors  due  to  manual  misconfiguration  or  human  errors  as  well 
as  an  improved  reproducibility. 

c)  Semi-automated  or  fully  automated  cross-checks  with  other  information  products  developed 
during  the  engineering  process  (e.g.,  whether  the  Federation  Object  Model  (FOM)  provides 
interaction  classes  for  all  communication  events  defined  in  the  scenario). 

3)  Reuse  is  simplified.  Scenario  specifications  may  be  archived  and  retrieved  for  later  reuse. 

Transfer  and  sharing  of  scenario  specifications  is  easily  possible. 

4.5  RELATION  OF  MATURITY  LEVELS  TO  SCENARIO  TYPES 

While  in  principle  each  maturity  level  may  be  assigned  to  any  of  the  three  types  of  scenarios,  in  practice  only 
certain  combinations  are  possible  or  likely.  Table  4-2  indicates: 
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•  Which  maturity  levels  are  generally  applicable  to  which  type  of  scenario  (non-empty  cells); 

•  Which  maturity  levels  are  currently  achieved  (C)  or  at  least  partially  achieved  (/C/);  and 

•  Which  maturity  levels  should  be  aimed  for  specifying  the  different  types  of  scenarios  (A). 


Table  4-2:  Relation  of  Maturity  Levels  to  the  Different  Types  of  Scenarios. 


Maturity  Level  of 

Scenario  Specification 

Type  of  Scenario 

Operational 

Scenario 

Conceptual 

Scenario 

Executable 

Scenario 

0  -  No  Written  Scenario  Specification 

C 

C 

1  -  Non-Standardized  Scenario  Specification 

C 

C 

C 

2  -  Standardized  Scenario  Specification 

ici 

ICI 

ICI 

3  -  Formal  Scenario  Specification 

A 

A 

/C/A 

Regarding  operational  scenarios,  in  our  experience  currently  non-standardized  scenario  specifications 
prevail.  Although  most  users  follow  some  kind  of  schema  for  describing  operational  scenarios,  we  are  not 
aware  of  any  commonly  used  standard  or  even  template.  For  specifying  operational  scenarios,  the  mid-term 
target  should  be  to  achieve  maturity  Level  2.  A  necessary  prerequisite  for  achieving  this  is  the  development 
and  adoption  of  a  common  standard  for  specifying  operational  scenarios. 

Specifications  of  conceptual  scenarios  are  regularly  achieving  maturity  Levels  1  and  partially  also  Level  2. 
The  short-term  goal  should  be  to  consistently  achieve  maturity  Level  2  across  a  large  number  of  simulation 
environment  engineering  process  applications.  The  mid-term  to  long-term  target  should  be  maturity  Level  3, 
i.e.,  formally  specified  conceptual  scenarios.  A  critical  factor  for  achieving  this  target  will  be  the  availability 
of  specialized  tools  which  allow  a  formal  specification  of  conceptual  scenarios  by  M&S  experts  on  the  one 
hand,  and  which  provide  a  customized  presentation  and  output  of  the  conceptual  scenario  for  discussion  with 
the  user  and  sponsor  on  the  other  hand. 

Currently,  executable  scenarios  are  most  often  specified  on  maturity  Levels  1  and  2.  Approaches  for 
formally  specifying  scenarios  are  available  (e.g.,  MSDL),  but  are  not  as  regularly  used  as  they  could  be. 
A  reason  for  this  may  be  that  currently  available  standards  are  missing  important  features  or  are  not 
providing  enough  benefits  compared  to  currently  used  “legacy”  standards.  The  target  must  be  to  achieve 
maturity  Level  3  for  the  specification  of  executable  scenarios  in  order  to  realize  the  potential  benefits. 
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Table  5-1  lists  available  standards  and  tools  for  scenario  specification.  This  compilation  is  not  exhaustive  but 
tries  to  give  an  overview.  The  assignment  of  standards  and  tools  to  the  different  types  of  scenarios  indicates 
for  which  type  of  scenario  a  standard  or  tool  is  most  likely  to  be  used.  This  assignment  does  not  exclude  the 
use  of  a  standard  or  tool  for  a  different  type  of  scenario.  More  detailed  explanations  on  the  standards  and 
tools  are  given  in  the  following  subsections  and  may  also  be  found  in  AMSP-01  [AMSP-01]. 


Table  5-1:  Standards  and  Tools  for  Scenario  Specification. 


Maturity 

Level  of 
Scenario 
Specification 

Type  of  Scenario 

Operational  Scenario 

Conceptual  Scenario 

Executable  Scenario 

Standards 

Tools 

Standards 

Tools 

Standards 

Tools 

0-No 

Written 

Scenario 

Specification 

1  -  Non- 
Standardized 
Scenario 
Specification 

“Everybody 
uses  his  own 
standard.” 

DSEEP 

General 

purpose 

software 

Unified 

Modelling 

Language 

(UML) 

Systems 

Modelling 

Language 

(SysML) 

General 

purpose 

software 

Wiki  engines 

UML  editors 

Individual 

documentation 

(e-g-, 

MEL/MIL, 
story  books) 

General 

purpose 

software 

2  -  Stand¬ 
ardized 
Scenario 
Specification 

NATO 

Comprehensive 

Operations 

Planning 

Directive 

(formerly: 

“NATO 

Guidelines  for 

Operational 

Planning”) 

General 

purpose 

software 

NATO 

Architecture 

Framework 

(NAF) 

VEVA 

documentation 
guidelines 
(in  Germany) 

General 

purpose 

software 

Wiki  engines 

UML  editors 

Proprietary 
(vendor- 
specific)  data 
exchange 
formats 

3  -  Formal 

Scenario 

Specification 

C-BML 

JC31EDM 

ADatP-3 

Base  Object 
Models  (BOM) 

JEMM 

MSDL 

JTDS  Order  of 
Battle  Service 

C-BML 

C21EDM/JC31 

EDM 

XML 

editors 

MSDE, 

WebMSDE 

Saab 

Scemanta 

C2LG  GUI 

Exonaut 

Tool  Suite 
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5.1  STANDARDS  AND  TOOLS  FOR  OPERATIONAL  SCENARIOS 

5.1.1  DSEEP 

Type  of  Standard:  Open  standard,  publicly  available  from  SISO  and  IEEE. 

The  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP)  [DSEEP]  describes  a  generic 
7-step  process  for  developing  and  executing  a  simulation  environment.  Each  step  of  the  DSEEP  is  further 
sub-divided  into  more  specific  activities,  and  for  each  activity  inputs  and  outputs  are  specified  by  the 
DSEEP.  As  the  DSEEP  is  considered  as  a  generalized,  high-level  framework  which  has  to  be  adapted  to 
individual  needs,  the  DSEEP  does  not  provide  very  detailed  guidance  or  even  documentation  templates  for 
activity  outcomes.  It  is  assumed  that  each  organization  that  uses  the  DSEEP  provides  this  detailed  guidance 
as  part  of  the  individual  adaptation. 

Nevertheless,  the  DSEEP  provides  basic  guidance  on  the  content  of  a  scenario  specification  [DSEEP, 
p.  13ff.]. 

5.1.2  NATO  Comprehensive  Operations  Planning  Directive 

Type  of  Standard:  Open  standard,  publicly  available. 

The  NATO  Comprehensive  Operations  Planning  Directive  (COPD)  [NATO  COPD]  (formerly:  “NATO 
Guidelines  for  Operational  Planning”)  and  its  national  counterparts  define  operational  planning  procedures. 
Although  these  planning  procedures  are  not  dedicated  solely  to  scenario  development  they  are  agreed 
guidelines  and  can  thus  be  seen  as  standards. 

5.1.3  General  Purpose  Software 

Type  of  Tool:  Open  tool,  publicly  available. 

Any  general-purpose  software  may  be  used  to  document  scenarios.  Typically  used  software  includes: 

•  Word  processors  (e.g.,  MS  Word,  OpenOffice  Writer). 

•  Presentation  programs  (e.g.,  MS  PowerPoint,  OpenOffice  Impress). 

•  Graphics  editors  (e.g.,  Adobe  Photoshop,  gimp). 

5.1.4  Joint  C3  Information  Exchange  Data  Model  (JC3IEDM) 

Type  of  Standard:  Open  standard,  publicly  available  from  Multi-lateral  Interoperability  Programme  (MIP). 

The  Joint  Consultation,  Command,  and  Control  Information  Exchange  Data  Model  (JC3IEDM)  [JC3IEDM] 
is  a  data  exchange  model  that  aims  to  improve  interoperability  between  systems  that  exchange  Command 
and  Control  (C2)  information.  The  JC31EDM  development  is  managed  by  the  Multi-lateral  Interoperability 
Programme  (MIP). 

Following  [JC31EDM]  the  scope  of  this  data  model  is  directed  at  producing  a  corporate  view  of  the  data  that 
reflects  the  multi-national  military  information  exchange  requirements  for  multiple  echelons  in  joint/ 
combined  wartime  and  Crisis  Response  Operations  (CRO).  The  data  model  is  focused  on  information  that 
supports: 

•  Situational  awareness; 

•  Operational  planning; 
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•  Execution;  and 

•  Reporting. 

The  scope  includes  data  from  various  functional  areas  according  to  the  requirements  levied  by  MIP  and 
NATO. 

As  the  JC31EDM  is  used  to  describe  operational  situations  it  is  obvious  that  it  may  also  be  used  to  describe 
operational  scenarios. 

5.1.5  Allied  Data  Publication  3  (ADatP-3) 

Type  of  Standard:  NATO  STANAG. 

As  explained  by  [ADatP-3]  the  standard  provides  the  rules,  constructions  and  vocabulary  for  standardised 
character-oriented  message  text  formats  that  can  be  used  in  both  manual  and  computer-assisted  operational 
environments.  These  message  formats  are  to  be  used  for  all  formatted  character-oriented  messages  within  the 
NATO  Command,  Control  and  Information  System  (NCCIS)  unless  specifically  excluded  by  multi-national 
agreement.  It  is  concerned  solely  with  the  part  of  a  message  that  contains  the  thought  or  idea  the  originator 
wishes  to  communicate.  The  transmission  of  formatted  messages  remains  in  accordance  with  the  instructions 
given  in  relevant  Allied  Communications  Publications. 

As  ADatP-3  is  used  to  describe  operational  situations  (like  JC3IEDM)  it  is  obvious  that  it  may  also  be  used 
to  describe  operational  scenarios. 

5.1.6  Coalition-Battle  Management  Language  (C-BML) 

Type  of  Standard:  Open  standard ,  publicly  available  from  SISO. 

The  Coalition-Battle  Management  Language  (C-BML)  currently  under  development  by  SISO  provides  an 
effort  for  a  publicly  available  standard  which  may  be  used  for  specifying  the  course  of  events  within  a 
scenario. 

5.2  STANDARDS  AND  TOOLS  FOR  CONCEPTUAL  SCENARIOS 

5.2.1  NATO  Architecture  Framework  (NAF) 

Type  of  Standard:  Open  standard,  publicly  available. 

The  NATO  Architecture  Framework  (NAF)  [NAF]  defines  several  views  which  may  be  used  for 
documenting  a  simulation  environment  engineering  process  (as  described  in  [EU  CTF]  and  [10S-SIW-027]). 
The  NAF  defines  only  the  content  of  the  various  views,  but  not  how  these  views  should  be  filled  (i.e.,  which 
methodologies  or  modelling  languages  should  be  used).  Furthermore,  the  NAF  is  originally  intended  for 
developing  and  describing  complex  (hardware  and  software)  systems  and  not  specifically  for  documenting 
scenarios.  Although  NAF  does  not  directly  address  scenario  documentation  it  may  be  used  for  this  purpose 
(see  Annex  A  for  an  example). 

5.2.2  Unified  Modeling  Language  (UML) 

Type  of  Standard:  Open  standard,  publicly  available  from  OMG  and  ISO/IEC. 
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Also,  the  Unified  Modeling  Language  (UML)  [UML]  defines  several  diagram  types  which  may  be  used  to 
document  specific  parts  of  a  scenario.  For  example,  class  diagrams  may  be  used  to  define  unit  hierarchies 
and  deployment  diagrams  may  be  used  to  document  which  units  are  simulated  by  which  simulation  system. 
As  the  UML  is  a  generic  modelling  language  it  is  not  specifically  designed  for  documenting  scenarios. 

5.2.3  Systems  Modelling  Language  (SysML) 

Type  of  Standard:  Open  standard ,  publicly  available  from  OMG. 

The  UML  language  comes  from  the  software  engineering  world.  The  system  engineering  world  has  derived 
the  Systems  Modelling  Language  (SysML)  from  UML.  Large  parts  of  UML  and  SysML  overlap,  but  SysML 
adds  two  additional  diagram  types:  requirements  diagrams  and  parametric  diagrams.  The  first  can  be  used  for 
requirements  analysis  and  the  latter  for  engineering  analysis  of  critical  system  parameters.  Given  that  a 
distributed  simulation  environment  is  more  than  software  only,  SysML  could  be  beneficial  for  the 
development  of  a  distributed  simulation  environment.  Specifically  for  specifying  scenarios  there  is  probably 
not  too  much  difference  between  using  UML  or  SysML. 

5.2.4  Base  Object  Models  (BOMs) 

Type  of  Standard:  Open  standard,  publicly  available  from  SISO. 

A  standard  which  directly  addresses  defining  and  reusing  components  of  models,  simulations  and  federations 
is  the  Base  Object  Model  (BOM)  Template  Specification  [BOM],  As  described  therein,  “BOMs  serve  to 
provide  an  end-state  of  a  simulation  conceptual  model  and  can  be  used  as  a  foundation  for  the  design  of 
executable  software  code  and  integration  of  interoperable  simulations.”  Regarding  scenario  documentation: 

“The  aspects  of  a  simulation  conceptual  model  found  in  a  BOM  contain  static  descriptions  of  items 
resident  in  the  real  world  described  in  terms  of  conceptual  entities  and  conceptual  ev’ents.  In  addition, 
those  aspects  of  a  simulation  conceptual  model  found  in  a  BOM  contain  information  on  how  such 
items  relate  or  interact  with  each  other  in  the  real  world  in  terms  of  patterns  of  interplay  and  state 
machines.”  [BOM,  p.  7] 

A  detailed  analysis  regarding  usability  and  practicability  of  using  BOMs  for  scenario  documentation  is 
presented  in  [13S-SIW-019],  Also,  Annexes  B  and  C  provide  examples  for  the  usage  of  BOMs  for  scenario 
specification. 

5.2.5  VEVA  Process  Model 

Type  of  Standard:  Local  standard,  used  by  German  Aimed  Forces,  partially  publicly  available. 

Representatives  of  a  different  approach  are  the  VEVA  documentation  guidelines.  The  VEVA  process  model 
is  a  German  approach  for  operationalizing  the  DSEEP  and  provides  detailed  documentation  guidelines 
covering  the  whole  simulation  environment  engineering  process  [1 1S-S1W-044]  [1 1F-S1W-023] 
[Siegfried2010].  Especially,  the  VEVA  documentation  guidelines  provide  specialized  documentation 
templates  for  scenarios.  The  documentation  templates  defined  by  VEVA  are  most  applicable  for 
documentation  of  operational  scenarios  and  conceptual  scenarios.  Obviously,  the  VEVA  is  not  an  official, 
public  standard,  but  as  the  VEVA  is  used  regularly  within  the  German  Armed  Forces  it  is  considered  as  a 
standard  (in  the  sense  of  the  definition  given  in  Section  4.3). 

5.2.6  Joint  Exercise  Management  Module  (JEMM) 

Type  of  Tool:  Local  tool,  available  from  NCIA. 
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JEMM  (NC3A  Joint  Exercise  Management  Module)  [Cayirci2010]  is  a  so-called  “Exercise  and  Scenario 
Management  Tool”. 

Exercise  and  Scenario  Management  tools  can  be  used  for  the  automation  of  processes,  information 
management  and  information  exchange  throughout  an  exercise  process.  They  can  help  in  preparation  and 
management  of  scenarios  as  well  as  the  Main  Event  and  Master  Incident  Lists  (MEL/MIL).  A  MEL/MIL 
tool  can  also  be  very  useful  in  synchronizing  and  managing  the  flow  of  an  exercise  according  to  the  exercise 
objectives,  as  well  as,  planning,  collecting  and  analyzing  the  observations.  MSG-068  used  JEMM  for  this 
purpose  [NMSG-068], 


5.3  STANDARDS  AND  TOOLS  FOR  EXECUTABLE  SCENARIOS 

5.3.1  Military  Scenario  Definition  Language  (MSDL) 

Type  of  Standard:  Open  standard ,  publicly  available  from  SISO. 

The  most  widely  known  and  publicly  available  standard  for  specifying  executable  scenarios  is  the  Military 
Scenario  Definition  Language  (MSDL)  [MSDL]  which  is  developed  and  maintained  by  SISO.  In  its  current 
version,  MSDL  allows  especially  the  specification  of  the  initial  state  of  a  scenario.  Dynamic  properties  of  a 
scenario  (i.e.,  course  of  events)  are  currently  not  part  of  the  MSDL. 

5.3.2  Order  of  Battle  Service  (OBS) 

Type  of  Standard:  Local  standard  used  by  JTDS. 

The  Order  of  Battle  Service  (OBS)  which  is  part  of  the  US  Joint  Training  Data  Services  (JTDS)  provides 
pre-populated  Order  of  Battle  data  sets  for  use  within  the  Joint  Live,  Virtual,  Constructive  (JLVC) 
Federation  [1 1F-SIW-034].  The  JTDS  OBS  XML  Schema  defines  the  XML  interchange  format  used  to 
exchange  initialization  data  between  JTDS  and  the  JLVC  federation.  Similar  to  MSDL,  the  OBS  XML 
Schema  allows  representation  of  force  sides,  units,  facilities,  relationships,  etc.  Due  to  various  reasons, 
the  OBS  XML  Schema  was  developed  in  parallel  with  MSDL  [MSDL]. 
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This  annex  describes  how  the  development  of  a  scenario  may  be  supported  and  documented  using  the  NATO 
Architecture  Framework  (NAF). 


A.l  RATIONALE 

The  following  citation  from  [NAF]  roughly  describes  what  is  commonly  understood  by  the  term 
“architecture”: 

An  architecture  is  the  fundamental  organisation  of  a  system  embodied  in  its  components,  their 
relationships  to  each  other  and  to  the  environment  and  the  principles  guiding  its  design  and 
evolution.  [...]  An  architecture  is  little  more  than  a  plan  put  together  in  accordance  with  certain 
rules. 

When  creating  an  architecture,  the  architect  normally  uses  a  specific  type  of  formal  description  for  their 
work.  Documenting  the  architecture  in  a  formalized  way  ensures  that  every  expert  capable  in  understanding 
the  formal  notion  can  also  read  and  understand  the  architecture,  its  elements,  relations  and  ideas  expressed 
therein.  This  fosters  coherent  design  and  reuse. 

Depending  on  the  specific  domain  many  formal  notions  of  architectures  have  evolved,  e.g.,  floor  plans  in  the 
construction  domain  or  UML  diagrams  in  the  software  domain.  The  formalized  notion  for  an  architecture 
within  a  single  application  domain  may  be  called  “architecture  framework”.  It  typically  comprises  some  kind 
of  symbology,  elements  of  the  domain,  their  abstract  roles  and  relationships  and  the  integration  of  these  parts 
into  different  views  (plans)  according  to  certain  templates. 

In  this  sense  the  NATO  Architecture  Framework  (NAF)  provides  many  different  views  and  related  templates 
to  describe  system  architectures  to  be  used  in  the  NATO  military  domain  for  different  purposes  like  for 
example: 

•  Capabilities  Integration,  Development  and  Portfolio; 

•  Planning,  Programming  and  Execution; 

•  Acquisition; 

•  Systems  Engineering;  and 

•  Operations  Planning. 

Several  of  these  activities  will  also  have  to  be  carried  out  on  the  design  and  execution  of  distributed 
simulation.  According  to  [DSEEP]  for  example  the  following  tasks  will  occur: 

•  Develop  Objectives,  Initial  Planning  (Capabilities,  Portfolio); 

•  Develop  Scenario  (Operations  Planning);  and 

•  Develop  and  Integrate  Simulation  Environment  (Systems  Engineering). 

Due  to  the  similarity  of  the  real-world  military  domain  and  the  design  of  simulation  environments  and 
simulations  for  the  military  domain,  it  is  very  likely  that  at  least  some  parts  of  the  NAF  will  also  be  helpful 
to  support  the  design  and  execution  of  distributed  simulation.  Extensive  work  has  been  carried  out  in 
[10S-SIW-027]  to  analyse  and  demonstrate  the  usability  of  architecture  frameworks  in  this  context  (using  the 
Ministry  of  Defence  Architecture  Framework  MoDAF  instead  of  NAF).  Following  these  ideas  and  convinced 
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of  the  general  usability  of  NAF  in  the  context  of  distributed  simulation  in  the  military  domain  in  the 
following  sections  concentrates  on  the  question  on  how  the  development  of  a  scenario  may  be  supported 
using  the  NAF. 

It  should  be  pointed  out,  that  this  use  of  architectures  and  the  corresponding  frameworks  must  not  be 
confused  with  simulation  architectures  like  the  High  Level  Architecture  (HLA).  Although  the  latter  describes 
federates,  object  models  and  federation  rules  and  therefore  forms  some  kind  of  architecture  framework, 
it  concentrates  on  the  construction  of  distributed  simulation  systems  only  and  lacks  the  templates  necessary 
to  describe  scenarios. 


A.2  ARCHITECTURES  IN  THE  SCENARIO  DEVELOPMENT  PROCESS 

Section  2.2  explains  the  differences  between  operational,  conceptual  and  executable  scenarios  within  the 
scenario  development  process. 

Operational  scenarios  have  to  be  provided  by  the  user  and  form  the  starting  point  of  the  scenario  development 
process.  They  are  described  in  terms  the  user  is  familiar  with  and  often  are  a  combination  of  graphical  and 
textual  descriptions  of  involved  entities,  actions,  tasks  and  events.  The  user  normally  will  not  be  aware  that 
by  creating  these  graphical  and  textual  descriptions  they  may  actually  be  creating  a  NAF  NOV-1  High  Level 
Operational  Concept  Description.  Also  their  description  may  contain  information  on  doctrine,  tactics, 
and  procedures,  concepts  of  operations,  environmental  conditions,  and  technical  standards  to  be  used  and  so 
on.  From  the  NAF  point  of  view  such  information  is  captured  in  templates  from  the  NAV  All  View, 
NOV  Operational  View,  NSV  System  View  and  NTV  Technical  View  sections.  However,  the  user  normally 
is  not  familiar  with  the  NAF  and  will  have  no  support  by  an  architecture  expert  during  the  creation  of  the 
operational  scenario.  Although  the  use  of  NAF  templates  even  in  this  early  phase  of  scenario  development 
would  be  feasible  and  desirable,  normally  operational  scenarios  are  being  developed  without  any  relations  to 
the  NAF. 

Conceptual  scenarios  refine  the  operational  scenarios.  They  are  created  by  M&S  experts  by  analysing 
the  operational  scenario  and  extracting  the  conceptual  information  necessary  to  construct  a  simulation 
environment  matching  the  operational  scenario.  It  is  obvious,  that  this  work  will  benefit  from  the  application 
of  NAF  because  the  main  goal  of  NAF  is  the  support  of  the  analysis  and  design  of  complex  systems  and 
finally  creating  an  architecture  of  the  system  to  be  constructed.  This  will  be  detailed  in  the  next  section. 
However,  it  should  be  noted  here  that  an  M&S  expert  is  not  necessarily  a  NAF -aware  system  architect. 
To  gain  optimal  results,  a  system  architect  familiar  with  the  NAF  should  be  involved  in  the  development  of 
the  conceptual  scenario,  at  least  as  long  as  the  M&S  experts  are  not  familiar  with  the  NAF  themselves. 

Executable  scenarios  finally  contain  all  information  necessary  for  preparation,  initialization  and  execution  of 
the  simulation  environment.  They  contain  the  most  detailed  specification  of  the  scenario  and  are  derived 
from  the  corresponding  conceptual  scenarios  by  M&S  experts  and  system  operators,  preferably  in  machine 
readable  form.  The  use  of  NAF  templates  to  describe  these  detailed  scenarios  probably  won’t  be  feasible, 
because  the  information  to  be  captured  in  most  cases  will  be  too  specific  to  be  described  by  NAF  templates. 
In  addition  there  is  no  standardized  machine-readable  format  for  NAF. 


A.3  NAF  TEMPLATES  FOR  CONCEPTUAL  SCENARIOS 

The  analysis  in  the  previous  section  shows,  that  the  derivation  of  conceptual  scenarios  from  operational 
scenarios  will  benefit  most  from  the  use  of  NAF. 

The  typical  architecture  creation  process  does  not  follow  any  specific  sequence  of  templates,  nor  will  all 
templates  featured  by  the  framework  have  to  be  created  for  the  description  of  a  particular  architecture. 
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Instead  the  decision  on  the  templates  to  be  created  and  the  sequence  of  template  creation  has  to  be  made  on  a 
case  by  case  basis  to  gain  optimal  results.  For  a  description  of  conceptual  scenarios  using  templates  of  the 
NAF  a  good  starting  point  would  be  the  creation  of  the  NAF  operational  view,  because  the  operational 
scenario  is  already  present  and  will  provide  a  good  starting  point.  Therefore  the  following  sequence  of  steps 
is  proposed  as  a  guideline. 

A.3.1  NOV  Operational  View 

The  creation  of  the  operational  view  mainly  consists  of  a  capturing  and  structuring  of  information  already 
present  in  the  operational  scenario  in  an  unstructured  form.  Following  and  augmenting  the  recommendations 
from  [10S-SIW-027],  the  NOV  templates  from  the  NAF  may  be  used  in  this  way. 


Table  A-1 :  Usability  of  NAF  Operational  View  Templates  for  the  Description  of  Scenarios. 


NAF  Template 

Usage 

NOV-1 

High-Level  Operational 
Concept 

Describe  the  context,  major  entities  and  actions  involved  in  the  operation. 

May  already  be  available  in  the  operational  scenario  description. 

Additional  constraints  or  preferences,  e.g.,  on  environmental  conditions  may 
be  stated  here. 

NOV-2 

Operational  Node 
Connectivity 

Describe  operational  nodes  and  their  roles  and  collaboration  patterns  from 
an  operational  point  of  view. 

Describe  activities  to  be  performed  by  nodes. 

NOV-3 

Operational  Information 
Requirements 

Describe  operational  information  to  be  exchanged  among  the  nodes. 

NOV-4 

Organizational 

Relationships 

Describe  organizational  relationships  if  relevant  for  the  operation. 

NOV-5 

Operational  Activities 

Describe  activities  that  are  relevant  for  the  operational  scenario. 

NOV-6 

Operational  Activities 
Sequence  and  Timing 

Describe  the  sequencing  of  activities  and  events. 

According  to  NAF,  operational  nodes  are  logical  collections  of  operational  activities.  Operational  nodes  produce  or 
consume  information  and  may  represent  an  operational  realization  of  capabilities. 


We  explicitly  note  here  that  this  proposed  structuring  of  operational  information  in  NAF  templates  has 
nothing  to  do  with  simulation.  It  is  the  same  task  as  designing,  e.g.,  a  defence  architecture  using  real  weapon 
systems  on  the  basis  of  a  real-world  operational  scenario.  The  transformation  to  a  simulation  environment 
occurs  at  a  later  stage  by  replacing  the  real  systems  by  simulation  models  with  the  appropriate  capabilities. 

Given  the  operational  scenario  from  Annex  C  for  example  the  NOV-5  activity  tree  may  look  as  depicted  in 
Figure  A-1. 
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Figure  A-1:  NOV-5  Operational  Activity  Tree  for  Scenario  Example  from  Annex  C. 


For  the  example  operational  scenario  (see  Annex  C)  two  operational  nodes  may  be  identified,  the  AH-1 
helicopter  and  the  infantry  troop,  and  assign  operational  activities  to  the  nodes.  To  express  the  opponent  role 
of  the  helicopter,  different  colours  for  the  operational  nodes  are  used.  No  operational  information  is  exchanges 
between  the  nodes,  so  (in  NAF  terminology)  a  “need  line”  between  the  nodes  is  missing.  Additionally  the 
nodes  may  be  attributed  with  the  activities  performed  at  the  nodes.  The  NOV -2  operational  node 
connectivity  diagram  then  might  look  as  shown  in  Figure  A-2. 


Figure  A-2:  NOV-2  Operational  Nodes  for  Scenario  Example  from  Annex  C. 


A.3.2  NSV  System  View 

In  a  next  step  some  templates  of  the  NAF  System  View  may  be  deduced  from  the  operational  view.  In  this 
phase  special  M&S  knowledge  will  be  necessary  because  the  systems  will  not  be  real-world  weapon  systems, 
but  will  be  simulation  systems  or  individual  simulation  models  and  therefore  their  specific  requirements  will 
have  to  be  taken  into  account. 

According  to  [10S-SIW-027]  Table  A-2  below,  the  following  NSV  templates  from  the  NAF  are  useful. 
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Table  A-2:  Usability  of  NAF  System  View  Templates  for  the  Description  of  Scenarios. 


NAF  Template 

Usage 

NSV-1 

System  Interfaces 

Describe  the  interfaces  (simulated  operational  interfaces  and  simulation 
specific  interfaces)  of  the  systems. 

NSV-2 

System  Communication 

Describe  system  or  model  communication,  message  exchanges  and 
(simulation)  communication  quality  requirements. 

NSV-5 

System  Functions  to 

Operational  Activity  Tracing 

Describe  system  functions  (e.g.,  model  capabilities)  necessary  to 
perform  the  required  operational  activities. 

NSV-4 

System  Functionality 

Describe  systems  or  models  to  be  present  and  their  functionality  to  be 
represented. 

NSV-1 0 

Rules,  Sequence  and  Timing 

Describe  system  rules,  state  transitions  and  event  traces. 

NSV-1 1 

System  Data  Model 

Describe  data  to  be  represented  in  the  simulation  environment, 
may  be  focused  on  exchanged  data  (FOM,  in  FIFA  terminology). 

Continuing  the  example  from  above,  the  list  of  system  functions  (1st  column)  and  their  mapping  to  operational 
activities  (1st  row,  see  table  above)  as  NSV-5  matrix  may  appear  as  presented  in  Table  A-3  below. 


Table  A-3:  NSV-5  Operational  Activities  to  System  Function 
Traceability  Matrix  for  Scenario  Example  from  Annex  C. 


Move 

Detect 

Engage 

Dispense  Flares 

Radar  Detection 

X 

Visual  Detection 

X 

IR  Detection 

X 

Flight  Helicopter 

X 

Flight  Missile 

X 

Flight  Flare 

X 

X 

IR  Emission 

X 

X 

Radar  Reflection 

X 

Each  of  the  operational  activities  thereby  requires  one  or  several  system  functions  to  be  implemented  in  the 
system.  These  system  functions  therefore  may  be  identified  with  individual  functions  or  capabilities  of 
simulation  models.  Similar  to  the  assignment  of  operational  activities  to  operational  nodes  in  the  operational 
view,  these  system  functions  may  be  assigned  to  individual  systems.  From  the  assignment  of  system  functions 
to  system  nodes  and  from  the  necessary  data  flows  between  the  system  functions  then  follows  the  NSV-2 
System  Communication  template. 
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Figure  A-3:  NSV-2  System  Communication  Template  for  Scenario  Example  from  Annex  C. 

Here  the  green  boxes  denote  the  individual  simulation  models,  which  implement  the  system  functions  listed 
in  the  table.  Each  of  the  models  may  contain  sub-models  not  shown  in  this  figure,  e.g.,  the  missile  model 
may  be  composed  of  a  movement  model  (implementing  the  “flight  missile”  system  function)  and  an  1R 
seeker  model  (implementing  the  “IR  detection”  system  function).  In  contrast  to  the  NOV -2  operational  node 
connectivity  diagram  there  is  intensive  data  exchange  between  the  individual  systems/models.  This  is 
depicted  by  the  connection  lines  in  the  figure  above,  the  transmitted  information  and  direction  of  data  flow 
indicated  by  the  arrows  and  their  labels. 

For  example,  the  infantry  troop  model  needs  information  on  position  and  movement  of  the  helicopter 
to  implement  the  visual  detection  system  function.  On  detection  it  will  launch  the  missile  (model). 
The  helicopter  model  will  need  the  position  information  from  the  missile  model  to  implement  radar  detection 
of  the  missile  and  to  launch  the  flare.  The  missile  will  need  position  information  from  the  helicopter  and  the 
flare  to  implement  target  detection,  guidance  and  distortion  of  detection/guidance  by  IR  emissions  from  the 
flare. 

It  is  obvious,  that  these  information  exchanges  form  a  starting  point  for  the  definition  of  the  data  (exchange) 
model  NSV-1 1  (the  FOM  in  HFA  terminology)  or  a  description  of  event  sequence  and  timing  NSV-10. 

A.3.3  Other  Views  and  Templates 

In  addition  to  the  templates  listed  above  several  other  templates  from  the  NAF  may  be  used  to  further  detail 
the  conceptual  scenario  description.  Examples  are: 

•  NTV-1  Technical  Standards  Profile:  Describes  the  (simulation  and  operational)  technical  standards 
to  be  followed; 

•  NTV-3  Standard  Configuration:  Describes  the  standard  system  configurations  that  are  known  to 
work;  and 

•  NAV-2  Integrated  Dictionary. 
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B.l  OVERVIEW  OF  THE  BOM  STANDARD 

As  stated  in  [BOM],  “Base  Object  Models  (BOMs)  provide  a  component  framework  for  facilitating 
interoperability,  reuse,  and  composability”.  For  this  purpose  the  “Base  Object  Model  (BOM)  Template 
Specification”  defines  the  format  and  syntax  for  describing  the  elements  of  a  template  for  representing 
BOMs. 

A  Base  Object  Model  is  composed  of  four  major  components: 

•  Model  Identification  (Metadata); 

•  Conceptual  Model  Definition; 

•  Object  Model  Definition;  and 

•  Model  Mapping. 

All  four  components  are  described  in  more  detail  in  the  following  sub-sections. 

B.1.1  Model  Identification 

The  “Model  Identification”  component  of  a  BOM  associates  important  metadata  (i.e.,  information  about  the 
base  object  model  itself)  with  the  model.  This  information  is  necessary  for  purposes  of  search  and  retrieval 
of  BOMs  as  well  as  for  maintaining  traceability  and  facilitating  reuse  of  BOMs. 

B.1.2  Conceptual  Model  Definition 

The  “Conceptual  Model  Definition”  component  of  a  BOM  is  used  for  specifying  the  conceptual  model 
represented  by  this  BOM.  For  defining  the  conceptual  model  the  BOM  Template  Specification  defines  four 
template  components  as  sub-components  of  the  “Conceptual  Model  Definition”: 

•  Entity  Type; 

•  Pattern  of  Interplay; 

•  State  Machine;  and 

•  Event  Type. 

The  entity  types  define  the  types  of  conceptual  entities  required  for  representing  all  aspects  of  the  conceptual 
model. 

The  pattern  of  interplay  defines  a  set  of  patterns  of  interplay  (including  pattern  actions,  variations, 
and  exceptions)  which  are  required  to  represent  the  activities  and  interactions  within  the  conceptual  model. 

The  state  machine  identifies  the  conceptual  entities  and  their  respective  states  as  well  as  the  state  transitions 
which  are  required  within  this  conceptual  model. 

The  event  types  define  types  of  conceptual  events  (directed,  undirected)  which  are  required  for  representing 
the  pattern  action  of  a  pattern  of  interplay. 
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B.1.3  Object  Model  Definition 

“The  Object  Model  Definition  defines  the  structure  of  object  and  interaction  classes,  and  their  associated 
attributed  and  parameters”  [BOM,  p.  48].  In  its  current  version,  the  BOM  Template  Specification  refers  to 
the  HLA  OMT  for  defining  object  and  interaction  classes  (e.g.,  using  the  classes  “HLA  Object  Class”  and 
“HI, A  Interaction  Class”  as  respective  root  classes  for  objects  and  interactions). 

B.1.4  Model  Mapping 

The  “Model  Mapping”  component  of  a  BOM  template  provides  the  link  between  the  entities  and  events  of 
the  Conceptual  Model  Definition  and  the  classes  specified  by  the  Object  Model  Definition. 

B.1.5  Documentation  of  BOMs 

Each  of  the  four  main  components  of  a  BOM  may  be  documented  and  represented  in  many  ways 
(e.g.,  textual,  tabular,  graphical).  Additionally,  the  BOM  Template  Specification  describes  the  BOM  Data 
Interchange  Format  (DIF).  The  BOM  DIF  is  specified  as  XMF  Schema  and  provides  the  possibility  to 
represent  a  BOM  as  XMF. 

Basically,  the  BOM  Template  Specification  uses  table-based  approach  for  specifying  data.  However,  almost 
all  tables  may  be  transformed  into  respective  UMF  diagrams  (e.g.,  sequence  diagrams  for  patterns  of 
interplay,  state  diagrams  for  state  machines).  Figure  B-l  shows  an  example. 


State  Machine 
Name 

Conceptual 

Entity 

State 

Note 

State 

Name 

Exit  Condition 

Exit  Action 

Next  State 

Ready 

CommandToFire 

Fire 

na 

ShootefStates 

FirtngEntity 

Greet 

WeaponFtreActton 

MunibonFlight 

na 

Seat 

Munition  DelonatlonActton 

Ready 

na 

Note 

na 

Figure  B-1:  Example  Specification  of  State  Machine  as  a 
Table  (Top)  and  as  a  Diagram  (Bottom)  [BOM], 
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B.2  EVALUATION 

In  Annex  C  an  operational  scenario  is  presented,  which  is  refined  into  a  conceptual  scenario.  First,  a  textual 
documentation  of  the  conceptual  scenario  is  shown  and  secondly  it  is  shown  how  the  conceptual  scenario 
may  be  documented  using  the  BOM  Template  Specification. 

B.2.1  Positive  Experiences 

The  BOM  standard  proved  to  be  very  useful  for  documenting  conceptual  scenarios  for  various  reasons. 

First,  the  formal  notation  imposed  by  the  BOM  Template  Specification  requires  a  scenario  developer  to  be 
much  more  precise  when  specifying  conceptual  scenarios  (compared  to  a  free-text  documentation  of 
conceptual  scenarios).  Especially  the  development  of  the  patterns  of  interplay  and  the  development  of  the 
state  machines  revealed  many  shortfalls  which  were  not  identified  when  developing  the  textual  documentation 
of  the  conceptual  scenario. 

Although  these  shortfalls  might  generally  also  be  identified  when  developing  a  textual  documentation, 
we  believe  that  the  usage  of  UML  as  formal  notation  (which  requires  precision)  simplifies  this  process  and 
requires  a  certain  scrutiny  of  scenario  developers.  Shortcuts  which  are  easily  taken  even  by  experienced 
developers  (e.g.,  due  to  missing  information  or  time)  are  a  lot  easier  to  identify  during  quality  management 
processes. 

Secondly,  the  well-structured  templates  of  the  BOM  standard  lead  to  a  well-structured  documentation  of 
conceptual  scenarios.  This  simplifies  both  understanding  and  comparing  conceptual  scenarios  as  the  reader 
(e.g.,  user,  model  developer,  or  V&V  agent)  is  familiar  with  the  way  a  conceptual  scenario  is  documented. 

The  possibility  to  document  (and  present!)  the  same  information  in  different  ways  is  further  supported  by 
the  BOM  standard  which  defines  at  least  three  different  representations:  tabular,  graphical,  BOM  DIF. 
This  allows  presenting  the  same  information  differently  for  different  users  (e.g.,  sequence  diagrams  for  user, 
BOM  DIF  for  tools). 

Finally,  the  BOM  Data  Interchange  Format  (DIF)  itself  is  a  great  advantage  of  the  BOM  standard.  The  BOM 
DIF  is  the  prerequisite  for  enabling  any  kind  of  tool  support  and  automated  processing  of  conceptual 
scenarios. 

B.2.2  Negative  Experiences 

Although  the  BOM  Template  Specification  was  very  useful,  the  focus  on  HLA  (especially  of  the  Object 
Model  Definition  and  Model  Mapping  components)  seems  to  be  a  drawback.  In  our  opinion,  the  BOM 
standard  would  benefit  if  terminology  would  be  relaxed  to  be  non-HLA-specific  and  aligned  with  DSEEP 
(which  is  architecture-neutral). 

B.2.3  Ideas  for  Improving  the  BOM  Standard 

Besides  relaxing  terminology,  it  would  be  beneficial  if  the  current  mapping  mechanism  of  the  BOM  standard 
(which  maps  entities  and  events  of  a  Conceptual  Model  Definition  onto  classes  defined  by  an  Object  Model 
Definition)  would  be  generalized.  Especially  in  the  context  of  scenario  specifications,  it  would  be  of  great 
value  if  mappings  between  entities  and  events  of  the  Conceptual  Model  Definition  and  arbitrary  elements 
defined  in  other  specifications  (e.g.,  in  MSDL  or  C-BML  files)  could  be  defined.  This  would  open  up  the 
opportunity  to  create  a  direct  link  between  the  specification  of  conceptual  scenarios  and  elements  of 
corresponding  executable  scenarios.  Such  links  would  also  allow  augmenting  the  specification  of  conceptual 
scenarios  with  more  detailed  specifications  where  necessary  and  would  improve  traceability  between 
conceptual  and  executable  scenarios  a  lot. 
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Annex  C  -  EXAMPLE  SCENARIO  “AIR  DEFENCE” 


The  example  scenario  “Air  defence”  is  concerned  with  the  study  of  the  operational  effectiveness  of  Man 
Portable  Air  Defence  (ManPAD)  systems  for  defending  a  manoeuvring  unit  against  airborne  attacks. 


C.l  DESCRIPTION  OF  THE  OPERATIONAL  SCENARIO 

A  ManPAD  team  consisting  of  a  commander,  an  observer  and  a  gunner,  is  supporting  a  manoeuvring  unit. 
The  ManPAD  team  is  deployed  around  400  metres  behind  the  manoeuvring  unit  on  high  ground.  At  the 
instant  when  the  ManPAD  commander  receives  an  early  warning  with  the  assumed  target  location, 
the  manoeuvring  unit  is  heading  north  and  the  ManPAD  team  is  behind  the  unit.  The  ManPAD  observer 
starts  searching  the  sector  from  which  the  aircraft  is  approaching. 


Figure  C-1:  Area  of  Interest. 

The  ManPAD  observer  catches  a  glimpse  of  a  blade  flash  from  rotating  helicopter  blades  approaching  from 
North.  Since  the  ManPAD  team  is  in  Weapons  Free  status,  the  ManPAD  gunner  starts  an  interrogation 
procedure.  As  soon  as  the  target  is  in  range  ring,  he  triggers  an  IFF  (identification  friend  or  foe)  operation. 
As  the  target  is  identified  as  hostile,  the  ManPAD  Commander  orders  a  Fire  Command. 

At  the  instant  of  fire,  the  enemy  helicopter  is  at  500  metres  altitude  and  has  a  speed  of  45  metres  per  second 
with  straight  flight.  The  ManPAD  gunner  launches  the  missile  from  80%  of  range  ring,  and  the  missile 
approaches  the  target  from  the  front.  As  soon  as  the  helicopter  detects  the  engagement,  it  throws  a  dozen 
flares  to  protect  against  the  missile  when  it  is  within  the  last  kilometre. 
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The  ManPAD  observer  then  evaluates  the  first  missile  and  reports  the  result  to  the  ManPAD  commander  for 
consecutive  action. 

C.2  TEXTUAL  DESCRIPTION  OF  THE  CONCEPTUAL  SCENARIO 

This  section  presents  a  typical  textual  description  of  a  conceptual  scenario.  The  textual  description  provided 
in  this  section  is  introduced  for  comparison  with  the  specification  of  the  conceptual  scenario  using  Base 
Object  Models  which  will  be  presented  in  the  following  section. 

The  textual  description  of  the  conceptual  scenario  follows  the  scenario  documentation  template  outlined  in 
Chapter  3. 

C.2.1  Initial  State 

The  initial  state  specifies  the  situation  at  the  beginning  of  the  scenario  time  line  which  includes  participating 
units,  forces  and  the  force  structure,  geography,  surrounding  conditions  and  the  rules  of  engagement.  Below 
is  the  initial  state  of  the  example  Air  Defence  scenario. 


C.2. 1.1  Units 


Unit 

Attribute 

Value 

Manoeuvring  Unit 

Initial  position 

0,  400,  0  in  Local  NED 

ManPAD  Team 

Initial  Position 

0,  0,  0  (Local  NED  origin) 

Sub  Units 

ManPAD  Commander,  ManPAD  Observer, 
ManPAD  Gunner 

Equipment  and  Weapons 

IFF  and  ManPAD-X 

Status 

Weapons  Free 

Target 

Type 

AEI-1  similar  helicopter 

Altitude 

500  metres 

Speed 

45  m\s  to  South  (-45,  0,  0) 

Manoeuvre 

Straight  flight 

Position 

0,  5500,  -500  in  Local  NED 

Engagement  Ring 

2500  m 

C.2. 1.2  Forces  and  Force  Structure 

ManPAD  Team 

•  Composed  of:  ManPAD  commander,  ManPAD  observer,  ManPAD  gunner. 

•  Command  structure:  ManPAD  observer  and  ManPAD  gunner  are  under  the  command  of  ManPAD 
Commander. 

•  Spatial  position:  All  three  units  at  the  same  location. 

•  C2:  Receives  voice  messages/commands  over  radio. 
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C.2.1.3  Geography 


Attribute 

Value 

Area 

Hypothetical  area 

Terrain 

Flat  earth 

Atmosphere 

ICAO  Standard 

Wind 

5  m/s  from  East 

C.2.1.4  Surrounding  Conditions 

Not  applicable. 

C.2.1.5  Rules  of  Engagement 

ManPAD  Team: 

1)  If  any  approaching  object  is  identified  and  the  status  is  Weapons  Free  then  IFF  operation  will  be 
triggered  as  soon  as  object  heads  into  the  range  ring;  and 

2)  If  object  is  identified  as  hostile  and  the  object  is  in  80%  of  range  ring,  weapon  is  fired. 

Helicopter: 

1 )  Apply  any  means  of  soft  kill  (flares,  manoeuvre,  etc.)  as  soon  as  a  missile  attack  is  detected;  and 

2)  Attack  any  manoeuvring  target  within  engagement  ring. 

C.2.2  Course  of  Events 

Besides  specifying  the  initial  conditions,  the  conceptual  scenario  shall  also  specify  pre-planned  events  that 
are  triggered  at  a  specific  time  or  due  to  a  specific  condition.  These  events  may  include  communication, 
interaction,  state  change  or  environmental  events.  The  course  of  events  in  the  example  air  defence  scenario  is 
provided  below. 


C.2.2.1  Communication  Events 


Time 

Event 

00:00 

ManPAD  commander  receives  a  voice  message  with  early  warning  information  for  a  target 
at  a  specific  position. 

C.2.2.2  Interaction  Events 


Event  Type 

Attribute(s) 

Trigger/Condition 

Target  Identification 

Target  Position 

Within  5  km  of  ManPAD  team 

IFF  Operation 

Target  Position 

In  the  range  ring  of  ManPAD  missile 

Missile  Fire 

IFF  Status 

Foe 

Target  Position 

In  80%  of  range  ring 

Missile  Detection 

Missile  Position 

Within  1.5  km  of  helicopter 
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Event  Type 

Attribute(s) 

Trigger/Condition 

Flare  Dispense 

Missile  Slant  Range 

1400  m 

Dispense  Number 

12 

Initial  Dispense  Time 

0.6  s 

Dispense  Interval  Time 

0.1  s 

C.2.3  Termination  Conditions 

Each  conceptual  scenario  shall  specify  termination  conditions  which  define  the  end  of  a  scenario.  Typical 
termination  conditions  can  be  that  a  predefined  time  has  elapsed  or  that  a  specific  condition  is  achieved. 
Below  is  the  termination  condition  of  the  example  air  defence  scenario. 

Termination  Condition:  The  missile  either  hits  the  target  or  misses  and  self-destructs. 


C.3  USING  BOMS  FOR  SCENARIO  SPECIFICATION 

This  section  describes  how  the  BOM  Template  is  used  for  specifying  the  conceptual  scenario  (in  contrast  to 
the  textual  description  of  the  conceptual  scenario  outlined  in  the  previous  section). 

C.3.1  Model  Identification 

We  are  convinced  that  the  “Model  Identification”  component  is  a  very  important  component  which  should 
always  be  specified  in  “real  world”  scenario  development  efforts.  Although  it  might  be  argued  that  it 
provides  little  additional  value  in  the  context  of  this  example,  we  deliberately  do  not  omit  the  “Model 
Identification”  component  of  the  BOM  Template  Specification. 


Category 

Information 

Name 

Air  defence  of  a  manoeuvring  unit  using  ManPADs 

Type 

BOM 

Version 

1.0 

Modification  Date 

2012-12-10 

Security  Classification 

Unclassified 

Release  Restriction 

Publicly  releasable 

Purpose 

Analysis  of  the  operational  effectiveness  of  Man  Portable  Air  Defence 
(ManPAD)  systems  for  defending  a  manoeuvring  unit  against  airborne 
attacks 

Application  Domain 

Analysis 

Description 

This  BOM  specifies  interactions  between  infantry  using  ManPADs  against 
helicopters 

Use  Limitation 

This  BOM  is  not  applicable  for  airborne  attacks  carried  out  by  jet  fighters  or 
bomber  units 
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Category 

Information 

Use  History 

Keyword 

Taxonomy 
Keyword  Value 

POC 

POC  Type 

POC  Name 

POC  Organization 
POC  Telephone 
POC  Email 

Primary  author 

Halit  Oguztiiziin 

POC 

POC  Type 

POC  Name 

POC  Organization 
POC  Telephone 
POC  Email 

Technical  POC 

Umut  Durak,  Aylin  Hatip 

Reference 

Type 

Identification 

None 

Other 

None 

Glyph 

Type 

Alt 

Height 

Width 

No  glyph  provided 

C.3.2  Conceptual  Model  Definition 

As  described  in  Section  2.2.2,  conceptual  scenarios  are  tightly  connected  to  the  conceptual  model  of  a 
simulation  enviromuent.  Strictly  speaking,  the  definition  of  entities  (and  their  properties)  is  part  of  the 
conceptual  model  and  not  part  of  a  conceptual  scenario.  However,  a  conceptual  scenario  will  usually  reference 
parts  of  a  conceptual  model  (e.g.,  entities). 

If  a  separate  documentation  of  a  conceptual  model  is  available  for  a  simulation  environment,  a  reference  to 
this  documentation  of  the  conceptual  model  may  be  included  in  the  “Reference”  sub-component  of  the 
“Model  Identification”  component.  Otherwise,  the  BOM  Template  provides  the  possibility  to  include 
information  about  entity  types,  etc.,  directly  into  the  BOM. 

C.3.2.1  Entity  Types 

The  BOM  is  made  of  several  key  elements;  one  of  them  is  the  conceptual  model.  Our  conceptual  model 
includes 

•  Commander  Entity; 

•  Observer  Entity; 

•  Gunner  Entity; 
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•  Hostile  Object  Entity; 

•  Firing  Entity;  and 

•  Target  Entity. 


Entity  Type 

Name 

Description 

Characteristics 

Description 

Commander 

Entity 

identifier 

Thing  that  is  the 
commander  information 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Observer 

Entity 

identifier 

Thing  that  is  the  observer 
information 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Gunner 

Entity 

identifier 

Thing  that  is  the  gunner 
information 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Hostile 

ObjectEntity 

identifier 

Thing  that  is  the  hostile 
object  information 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Velocity 

Velocity  for  the  entity 

Firing 

Entity 

identifier 

Thing  that  fires  a  weapon 
at  a  target 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Target 

Entity  identifer 

Thing  that  is  the  target 
information 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Velocity 

Velocity  for  the  entity 

MissileEntity 

identifier 

Thing  that  is  the  missile 
information 

ID 

Unique  ID  for  entity 

Location 

Physical  position  of  the  entity 

Velocity 

Velocity  for  the  entity 

C.3.2.2  Pattern  of  Interplay 

The  major  pattern  of  interplay  within  this  air  defence  scenario  is  the  sequence  from  observing  the  airspace 
until  detection,  identification  and  engagement  of  the  target. 
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This  pattern  of  interplay  is  illustrated  in  Figure  C-2  using  a  UML  sequence  diagram.  The  transitions  (arrows) 
are  amiotated  with  the  communication  and  interaction  events  between  actors.  We  chose  to  distinguish  two 
types  of  transitions  (mdicated  by  stereotypes  hi  Figure  C-2): 

•  Communication  (represents  exchange  of  information  between  two  parties):  and 

•  Action. 


sd  Pattern  of  Interplay  / 


ManPAD  Commander 


Man  PAD  Observer 


ManPAD  Gunner 


Target 


•Communication* 


*-r Early  wamingO 


•Communication* 


"Observe  airspace"-order() 


•Communication* 


Notification  about 
approaching  helicopterf) 


•Communication* 


•Action, Communication* 


Interrogation  procedure 
and  IFFQ 


•Communication* 


Report  of  hostile  objedO  L 

I 

_ 


Fire  commando 


•Action* 


Launch  missileO 


•Action*  Evaluate 
engagement) 


Target 

destroyed? 


•Communication* 


tr 


Report  damage  assessment) 


Figure  C-2:  Overview  of  Pattern  of  Interplay  in  Example  Scenario  “Air  Defence”. 

Currently,  the  distinction  is  used  only  for  clarifying  the  scenario  developers’  intention  and  the  chosen  types 
are  not  described  any  further.  Ideally,  a  scenario  developer  can  choose  from  a  set  of  well-defined  transition 
types  which  are  standardized  within  an  organization  or  across  the  M&S  community  (e.g.,  as  SISO  standard). 

During  development  of  the  sequence  diagram,  we  identified  a  couple  of  shortfalls  in  the  original  operational 
scenario: 

•  Who  sends  the  “early  warning”?  The  missing  information  is  mdicated  hi  Figure  C-2  by  using  “?”  for 
the  actor  that  sends  the  early  warning. 

•  What  precisely  is  the  “Interrogation  procedure  and  IFF”?  Within  the  sequence  diagram  we 
amiotated  this  transition  with  the  stereotypes  “Action"  and  “Communication”  to  indicate  that  it  may 
be  an  interaction  (e.g..  sending  an  IFF  request)  or  a  communication  (e.g..  radio  communication). 
However,  a  clear  description  of  this  procedure  is  missing. 

•  What  precisely  contains  the  “Report  of  hostile  object”? 

•  The  ManPAD  Observer  has  to  evaluate  the  engagement.  How  is  this  activity  triggered? 
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In  summary,  specifying  a  scenario  using  a  sequence  diagram  has  proven  very  useful  as  it  requires  a  scenario 
developer  to  be  much  more  precise  compared  to  textually  specifying  a  scenario. 

C.3.2.3  State  Machines 

The  Pattern  of  Interplay  gives  an  overview  over  the  whole  scenario,  but  does  not  provide  detailed  information 
about  behaviour  of  single  entities.  Specification  of  behaviour  of  single  entities  may  be  done  using  UML  state 
machines,  hi  the  following,  each  entity  of  the  example  scenario  is  described  and  its  behaviour  is  defined 
using  state  machines. 


ManPAD  Team 

The  state  machines  of  the  ManPAD  team  are  provided  in  Figure  C-3,  Figure  C-4.  and  Figure  C-5. 


stm  ManPAD  Commander 


Figure  C-3:  State  Machine  of  ManPAD  Commander. 
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stm  ManPAD  Observer 


X 


Idle 


<- 


«Communication» 
/"Observe  airspace"-order 


1 


/^Observing  airspaceN 


[Object  detected] 
/Notification  about 
approaching 
helicopter 


Figure  C-4:  State  Machine  of  ManPAD  Observer. 


stm  ManPAD  Gunner 


1 


Idle  \ 


<- 

<- 


«Communication» 
/Notification  about 
approaching  helicopterw 


Interrogation/I  FF 'X\ 


[IFF=friend] 


((Communication* 

[IFF=enemy] 

/Fire  command 


i 


Weapons  ready 


[Missile  launched] 


Figure  C-5:  State  Machine  of  ManPAD  Gunner. 
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Figure  C-3  shows  the  state  machine  of  the  ManPAD  Commander.  As  can  easily  be  conceived  from  the  state 
machine,  the  ManPAD  Commander  has  a  very  simple  behaviour.  Basically,  they  are  just  responding  to  the 
reception  of  an  early  warning  message  and  enter  the  “Active”-state  once  they  receive  this  communication. 
They  stay  in  “Active”-state  until  the  tar  get  was  successfully  destroyed. 

Figure  C-4  shows  the  state  machine  of  the  ManPAD  Observer.  Tire  observer  is  "Idle”  until  they  receive  an 
“Observe  airspace”-order.  The  observation  of  the  airspace  is  continued  until  an  object  is  detected,  hi  this 
case,  a  notification  is  send  to  the  ManPAD  gunner  and  the  ManPAD  observer  goes  back  into  “Idle”-state. 

Figure  C-5  presents  the  state  machine  of  the  ManPAD  Gunner.  The  gunner  is  “Idle”  until  they  receive  a 
“Notification  about  approaching  helicopter”.  Upon  reception  of  this  communication,  the  gunner  starts  the 
interrogation  procedure  and  IFF.  The  result  of  the  IFF  is  reported  back  to  the  ManPAD  Commander 
(see  Figure  C-2).  If  the  ManPAD  Commander  sends  the  “Fir  e  command”,  the  gunner  launches  a  missile  and 
goes  back  into  “Idle”. 

The  case  of  an  approaching  helicopter  being  identified  as  friendly  was  not  described  in  the  original  operational 
scenario.  Yet.  when  developing  the  conceptual  scenario  and  creating  the  state  machine  for  the  ManPAD 
Gunner,  it  became  obvious  that  such  a  state  transition  (as  indicated  Figure  C-5  in  by  “IFF=fiiend”) 
is  necessary.  Otherwise,  the  ManPAD  Gunner  would  be  stuck  once  they  are  in  “hiterrogation/IFF”-state. 

Figure  C-6  shows  the  state  machine  of  a  Target.  As  described  in  the  operational  scenario,  a  target  is  in 
straight  flight  until  an  approaching  missile  is  detected.  Upon  detection  of  an  approaching  missile,  the  target 
goes  into  “Self-defence”  state  and  throws  its  flares.  Depending  on  the  result  of  the  defensive  actions,  either 
the  missile  is  destroyed  (respectively  does  not  hit  and  destroy  the  target)  or  the  target  is  hit  and  destroyed. 


stm  Target 


T  arget 
destroyed 


Figure  C-6:  State  Machine  of  Target. 
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Finally.  Figure  C-7  shows  the  state  machine  of  the  Missile.  The  behaviour  of  a  missile  is  rather  simple. 
Once  launched,  a  missile  flies  towards  the  target  and  either  destroys  the  target  or  misses  the  target. 
Independently  of  the  result,  the  missile  is  destroyed. 


stm  Missile  ^ 

i 

\ 

1 

/ 

S'  Idle  N 

V  J 

[Missile  launched] 

\ 

L 

f  Flight 

V  J 

[Missile  destroyed 
by  target] 

Missile 

destroyed 

[Missile  hits 
target] 

Figure  C-7:  State  Machine  of  Missile. 


C.3.3  Object  Model  Definition  and  Model  Mapping 

The  Object  Model  Definition  and  Model  Mapping  components  of  the  BOM  Template  Specification  are 
neither  suitable  nor  necessary  for  documenting  conceptual  scenarios. 
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Annex  D  -  EXAMPLE  SCENARIO  “CLOSE  AIR  SUPPORT” 


In  this  annex,  an  example  is  given  how  the  information  products  related  to  scenario  can  be  applied  to  a  real 
world  scenario.  A  Close  Air  Support  scenario  is  described,  where  a  Forward  Air  Controller  (FAC)  team  on 
the  ground  and  a  flight  of  fighter  aircraft  work  together  to  deliver  a  laser-guided  weapon  on  a  target 
(see  [JP3-09.3]  for  more  details  about  Close  Air  Support  procedures).  This  example  is  based  on  work  also 
described  in  [Keuning2008]  and  [Voogd2009]. 

In  the  next  sections,  the  operational  scenario  and  conceptual  scenario  for  this  case  are  given. 


D.l  OPERATIONAL  SCENARIO 

Below  is  the  operational  scenario,  as  it  could  be  given  by  an  operational  person.  This  operational  scenario  is 
given  as  free  text,  so  it  is  using  an  unstructured  scenario  specification. 


A  friendly  infantry  unit  is  being  attacked  by  insurgents  from  a  building.  A  flight  of  two  F-16  aircraft  is  on 
a  close  air  support  mission  and  is  flying  above  the  mission  area.  The  aircraft  are  equipped  with  laser 
guided  bombs.  The  Forward  Air  Controller  (FAC)  team  of  the  infantry  unit  requests  air  support  from  the 
F-16  flight. 

The  flight  lead  determines  which  of  the  two  aircraft  will  deliver  the  close  air  support.  The  attacking  pilot 
contacts  the  FAC  team  on  the  ground.  The  FAC  team  requests  a  Type  1  CAS  attack  and  delivers  the 
information  about  the  target  using  the  standard  9  liner  procedure. 

Using  their  Targeting  Pod  (TGP),  and  while  communicating  with  the  FAC  team,  the  pilot  identifies  the 
target.  After  successful  identification  the  pilot  starts  their  attack  run.  They  will  only  release  their  weapon 
after  the  FAC  team  announced  CLEARED  HOT.  The  pilot  will  announce  when  the  weapon  is  10  seconds 
before  impact  and  at  the  moment  the  FAC  team  will  start  to  illuminate  the  target  with  their  laser. 

After  weapon  impact  the  damage  is  assessed  by  the  pilot  and  the  FAC  team.  If  needed,  another  attack  is 
made. 


D.2  CONCEPTUAL  SCENARIO 

D.2.1  Initial  State 

D.2.1.1  F-16  Flight 

•  Structure: 

•  Flight  lead;  and 

•  Wingman. 

•  Equipment: 

•  Radio; 

•  Laser  guided  bomb;  and 

•  Targeting  pod. 

•  Initial  position: 

•  In  a  holding  pattern  somewhere  above  the  battlefield. 
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The  UML  use  case  diagram  below  shows  the  actors  within  this  scenario  and  indicates  that  both  the  flight 
lead  and  the  wingman  can  become  the  attacking  aircraft  when  close  air  support  is  requested.  The  flight  lead 
will  determine  which  aircraft  is  in  the  best  position  to  deliver  the  support  once  the  request  is  made. 


D.2.1.2  FAC  Team 

•  Structure: 

•  Team  leader;  and 

•  Laser  operator. 

•  Equipment: 

•  Radio;  and 

•  Laser  designator. 

•  Initial  position: 

•  Near  the  infantry  unit;  and 

•  Within  visual  range  of  the  insurgents. 

The  UML  diagram  below  shows  the  two  roles  in  the  FAC  team  graphically. 


Figure  D-2:  Two  Roles  in  the  FAC  Team. 
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D.2.1.3  Infantry  Unit 

•  Initial  position: 

•  Near  insurgents. 

D.2.1.4  Insurgents 

•  Initial  position: 

•  Inside  a  building. 

D.2.1.5  Geography,  Date/Time 

•  Rural  environment. 

•  Day  time. 

D.2.1.6  Surrounding  Conditions 

•  Clear  weather. 

•  No  wind. 

D.2.1.7  Rules  of  Engagement 

•  F-16: 

•  Must  have  identified  the  target; 

•  Must  have  identified  the  location  of  friendly  forces  around  the  target;  and 

•  Must  have  received  CLEARED  HOT  instruction  from  FAC  team. 

D.2.2  Course  of  Action 

D.2.2.1  Communication  Events 

•  FAC  team  leader  requests  CAS  from  F-16  flight  lead. 

•  F-16  flight  lead  acknowledges  CAS  request. 

•  FAC  team  leader  provides  basic  target  information  to  F-16  flight  lead. 

•  F-16  flight  lead  reports  to  F-16  wingman  who  is  going  to  be  the  attacking  aircraft. 

•  FAC  team  leader  provides  detailed  target  information  to  the  attacking  F-16. 

•  Attacking  F-16  reports  ready  for  attach  run  once  target  has  been  identified. 

•  FAC  team  leader  reports  CLEARED  HOT  when  allowed  to  employ  weapon. 

•  Attacking  F-16  reports  to  FAC  team  leader  10  seconds  before  expected  weapon  impact. 

D.2.2.2  Interaction  Events 

•  Insurgents  fire  at  infantry  unit. 

•  Attacking  F-16  identifies  target  (building  with  insurgents). 
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•  Attacking  F-16  releases  laser-guided  bomb. 

•  FAC  team  laser  operator  illuminates  target  with  the  laser  designator. 

•  Laser-guided  bomb  acquires  laser  signal. 

•  Laser-guided  bomb  impacts  on  target  or  ground. 

D.2.2.3  Environmental  Events 

•  N/A. 

The  UML  activity  diagram  below  shows  the  basic  interactions  between  the  different  actors  in  the  scenario. 


Figure  D-3:  Scenario  Interactions  Between  Different  Actors. 
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D.2.3  Termination  Criteria 

•  Weapon  has  detonated  and  damage  has  been  assessed. 


D.3  DISCUSSION 

Compared  to  the  other  example  scenario,  this  example  has  chosen  a  different  level  of  detail  to  describe  certain 
elements  of  the  conceptual  scenario.  This  section  discusses  why  this  decision  has  been  made.  The  required 
amount  of  detail  should  be  balanced  for  each  specific  scenario. 

On  one  hand,  as  much  detail  as  possible  should  be  provided,  since  that  eases  the  task  to  transform  a 
conceptual  scenario  into  an  executable  scenario.  Any  detail  that  is  not  included  in  the  conceptual  scenario 
will  have  to  be  determined  by  the  developer  producing  the  executable  scenario. 

On  the  other  hand,  if  different  variants  of  the  same  scenario  are  used,  it  might  be  useful  to  make  the 
conceptual  scenario  more  generic,  since  that  allows  usage  of  the  same  conceptual  scenario  for  deriving 
multiple  executable  scenarios. 

In  the  specific  case  of  this  example  scenario,  two  variants  of  the  same  scenario  were  used  in  a  real-world 
project.  One  variant  situated  the  close  air  support  mission  in  a  training  context,  while  the  other  variant  put  it 
in  a  mission  rehearsal  context.  As  a  result  of  this,  the  conceptual  scenario  does  not  provide  very  detailed 
initial  position  and  related  information  of  the  different  units. 

When  describing  the  course  of  events,  the  different  interactions  have  been  described  slightly  more  detailed 
than  the  other  example  scenario.  This  has  been  done  because  the  different  interactions  going  on  between  the 
entities  in  the  scenario  were  an  important  aspect  in  the  project  the  scenario  comes  from.  Specifying  them  in 
more  detail  helped  with  the  development  of  the  conceptual  model. 
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